1. Target Overview

Machine Name: Poison
Platform: HackTheBox
Operating System: FreeBSD
Target IP:
Objective:

This target appears to expose a FreeBSD-based system hosted on HackTheBox. The goal of the engagement is to perform enumeration, identify attack vectors, gain an initial foothold on the system, and ultimately escalate privileges to obtain full administrative control of the machine. Initial reconnaissance indicates a relatively small attack surface, suggesting the exploitation path will likely rely on careful service enumeration rather than broad network exposure.

---

2. Enumeration

Network Enumeration

As always, I began the engagement with a standard Nmap service and version scan to identify exposed services on the target system.

The scan revealed two open ports, indicating a fairly limited attack surface.

Open Ports Identified

Port	Service	Version
22	SSH	OpenSSH 7.2 (FreeBSD)
80	HTTP	Apache httpd 2.4.29 (FreeBSD) running PHP 5.6.32

The SSH service appears to be a standard OpenSSH implementation on FreeBSD, which typically requires valid credentials and therefore does not present an immediate attack vector during early enumeration.

The more interesting discovery is port 80, which is hosting an Apache web server running PHP. Web applications frequently expose misconfigurations or vulnerable functionality, making them a strong candidate for initial exploitation.

Given the limited number of exposed services, I decided to prioritize enumeration of the web application running on port 80 as the most promising entry point.

Service Enumeration

The Nmap service detection confirms the following details about the web service:

• Apache httpd 2.4.29

• PHP 5.6.32

• Operating System: FreeBSD

The presence of PHP suggests that the site likely contains dynamic server-side functionality.

Web Enumeration

Upon visiting the web application at the root page, I was presented with a very simple interface designed to test local PHP scripts.

The page displayed several available scripts that could be executed through the application:

The interface contained a field labeled "Scriptname" to load from the available scripts, the most interesting of which was a script called listfiles.php. I used this file to test and see what would be returned.

Submitting the request loaded a page that returned a directory listing from the web root, showing the following files:

One file immediately stood out:

pwdbackup.txt

The name strongly suggested the presence of credential data or a password backup, making it a high-value target.

Navigating directly to the file through the browser revealed a long encoded string along with a message:

"This password is secure, it's encoded atleast 13 times, what could go wrong really."

The content appeared to be Base64 encoded data, and the message implied the string had been encoded multiple times.

Given this hint, the logical next step was to decode the string repeatedly to reveal the underlying credential.

so I wrote a quick loop in Bash to repeatedly decode it.

data=\((cat pass.b64); for i in {1..13}; do data=\)(echo \(data | tr -d ' ' | base64 -d); done; echo \)data

After the decoding process completed, the final output revealed the credential:

Charix!2#4%68&()

At this point I had successfully recovered a plaintext password. Since SSH is exposed on port 22, this credential could potentially be used to gain shell access.

However, I still did not have a valid username associated with this password. Rather than blindly guessing usernames against SSH, I decided the smarter approach was to continue enumerating the web application on port 80 to try to identify a user account that might correspond to this credential.

Earlier when exploring the test page, I noticed something important about how the application loaded scripts.

The request generated by the page looked like this:

browse.php?file=listfiles.php

The value of the file parameter was directly controlling which file the server attempted to load. Whenever a web application allows a user-supplied parameter to reference files on the system, it immediately becomes a prime candidate for a Local File Inclusion (LFI) vulnerability.

To test whether the parameter was vulnerable, I attempted to access a well-known system file:

The server returned the contents of the /etc/passwd file, confirming that the application was indeed vulnerable to Local File Inclusion.

The output revealed the list of system users on the machine.

After confirming the Local File Inclusion vulnerability by successfully retrieving /etc/passwd, I downloaded the returned file locally so I could analyze it more easily.

Rather than manually scanning through the entire file, I filtered the results to identify accounts that actually had interactive shells, since those are the only users that can realistically be used for SSH access.

I did this with the following command:

cat user.txt | grep "sh$"

This filters for lines ending in sh, which typically indicates a valid login shell such as /bin/sh, /bin/bash, or /bin/csh.

The output revealed only two users on the system with interactive shells:

This significantly narrowed the potential login targets. Since the root account typically cannot be accessed directly over SSH in most configurations, the most realistic user to target was charix.

Earlier during enumeration, I had already recovered a password from the encoded backup file:

Charix!2#4%68&()

At this point I had a strong candidate credential pair:

Username: charix
Password: Charix!2#4%68&()

With SSH exposed on port 22, the next logical step was to attempt authentication using these credentials to obtain an initial shell on the system.

3. Exploitation

Initial Access

Using the credentials discovered during enumeration, I attempted to authenticate to the target system via SSH.

ssh charix@10.129.1.254

After supplying the recovered password, authentication succeeded and I obtained a shell as the charix user.

charix@Poison:~ %

The login banner confirmed the system was running:

FreeBSD 11.1-RELEASE

At this stage I had successfully achieved initial access to the target system as a low-privileged user, allowing me to begin local enumeration in search of a privilege escalation path.

4. Privilege Escalation

Shell Stabilization

After obtaining an initial shell as charix, I began following my Linux privilege escalation methodology.

The first step is always to verify the execution context and confirm the user privileges.

whoami

Output:

charix

Next, I checked the user’s UID and group memberships.

id

This confirms the user context and sometimes reveals membership in privileged groups that may allow privilege escalation.

I then checked whether the user could execute any commands with elevated privileges through sudo.

sudo -l

No useful sudo privileges were returned for this user, so there was no immediate privilege escalation path through sudo.

---

System Enumeration

Following my privilege escalation checklist, the next step was to inspect the user’s home directory for interesting files.

While listing the contents of the directory, I discovered the following archive:

secret.zip

I extracted the archive to inspect its contents.

unzip secret.zip

The archive contained a file named:

secret

Running the file command revealed the following:

file secret

Output:

secret: Non-ISO extended-ASCII text, with no line terminators

To better understand the file’s contents, I examined the raw bytes.

cat secret | hexdump -C

Output:

00000000  bd a8 5b 7c d5 96 7a 21

The file appeared to contain binary data rather than readable text, which suggested it might represent some type of authentication token or encoded value. Since it was not immediately clear how the file would be used, I continued enumerating the system.

Next, I checked for services listening on the host using netstat to identify anything bound only to localhost.

netstat -an -p tcp

The results revealed several listening services. Most notably, I observed the following ports bound only to localhost:

127.0.0.1:5801
127.0.0.1:5901

Ports in the 5800–5900 range are commonly associated with VNC (Virtual Network Computing) services used for remote graphical desktop access.

To confirm which process was responsible for these ports, I inspected the process list.

ps -auwwx | grep vnc

This revealed the following process running under the root user:

root  529  0.0  0.9 23620 9036 v0- I  12:54  0:00.07  Xvnc :1 -desktop

This confirmed that a VNC server was running as root, but it was only accessible locally.

---

Privilege Escalation Vector

The presence of the Xvnc process running as root suggested a potential escalation path.

Xvnc is part of the X Window System, which provides graphical desktop functionality on Unix-like systems. Authentication for X sessions is typically handled through Xauthority cookies, which are secret tokens used to authenticate clients connecting to the graphical server.

These cookies are often stored as binary values, which immediately reminded me of the mysterious binary file discovered earlier in secret.zip.

This strongly suggested that the extracted file might contain the authentication token required to access the root VNC session.

Since the service was bound only to localhost, I created an SSH tunnel to forward the VNC port to my local machine.

ssh -L 5901:127.0.0.1:5901 charix@10.129.1.254

This allowed me to access the VNC service running on the target machine.

Using the authentication token from the extracted file, I attempted to connect to the VNC session.

The attempt was successful and granted access to the root user’s graphical desktop session.

---

Root Access

Once connected to the VNC desktop session, I opened a terminal window and confirmed my privileges.

At this point I had successfully escalated privileges and obtained full root access on the system.

5. Lessons Learned

Key Takeaways

1. Thoroughly test every piece of functionality exposed by a web application

   One of the biggest lessons from this machine was the importance of fully interacting with every feature exposed by a web application. The page we encountered was designed to test local PHP scripts and listed multiple scripts that could be executed. If I had only tested the first script and moved on, I never would have discovered the pwdbackup.txt file. Carefully testing each script and observing the results ultimately revealed the encoded credential that started the attack chain.

2. Pay close attention to the structure of web requests

   During testing I noticed that the application passed filenames through a query string parameter. Anytime you see parameters, file paths, or dynamic values in a request, it should immediately raise suspicion because those inputs are often attacker-controlled. Observing how the application constructed requests like:

   browse.php?file=listfiles.php
   

   revealed that the file parameter directly controlled which file the application loaded. Testing that parameter led directly to a Local File Inclusion vulnerability, which allowed me to retrieve /etc/passwd and identify valid system users.

3. Local File Inclusion can lead to Remote Code Execution through log poisoning

   Another important concept I learned from this machine was log poisoning as a method of turning LFI into Remote Code Execution.

   Once an LFI vulnerability is confirmed, the next step is to determine where server logs are stored, since logs often contain user-controlled data.

   On Apache systems this information can often be found in the Apache configuration file:

   /usr/local/etc/apache24/httpd.conf
   

   Reviewing this file revealed that the Apache access logs were stored at:

   /var/log/httpd-access.log
   

   The key trick here is understanding that certain values from every request made to the server are written directly into the access log, including HTTP headers.

   Using Burp Suite, it is possible to modify a request and place a PHP web shell inside a header field, commonly the User-Agent header.

   For example:

   <?php system($_GET['cmd']); ?>
   

   When the request is sent, this payload becomes written into the Apache access log. Because the application already allowed Local File Inclusion, I could then request the log file through the LFI vulnerability. When the log file is included by PHP, the injected code executes, giving remote command execution.

   This demonstrated how LFI vulnerabilities can often be escalated to full code execution if logs or other writable files can be included.

4. Checking the user’s home directory can reveal important artifacts

   During local enumeration, inspecting the user’s home directory revealed the file secret.zip. Even though the binary file extracted from it initially looked meaningless, it ultimately turned out to be the authentication token needed to access the root VNC session.

   This reinforces why checking a user's home directory early in privilege escalation is critical, since users frequently leave behind backups, credentials, or other sensitive files.

5. Enumerating local services can reveal hidden attack surfaces

   Using netstat revealed services listening only on localhost, including ports 5801 and 5901, which are commonly associated with VNC (Virtual Network Computing).

   These services would not have been visible externally during the initial Nmap scan, but once a foothold was obtained they became visible and ultimately led to the privilege escalation path.

6. Understanding VNC and X Window authentication mechanisms

   This machine introduced me to VNC services and the X Window system, which were new concepts for me. X Window uses authentication cookies to allow clients to connect to graphical sessions. The seemingly random binary file extracted from secret.zip was actually the authentication token required to connect to the running Xvnc session. Recognizing how this authentication mechanism worked made it possible to connect to the root graphical session and obtain full system access.

7. Knowing common configuration file locations is extremely useful

   Another takeaway from this box is the importance of knowing where important configuration files typically live. For Apache on FreeBSD systems, the configuration file is commonly located at:

   /usr/local/etc/apache24/httpd.conf
   

   Understanding where these files are stored makes it much easier to locate useful information such as log file locations, virtual host configurations, and other security-relevant settings.

8. Learning operational skills like secure file transfer is valuable

   During the process I also reinforced the usefulness of tools like scp for transferring files between the attacker machine and the target system. Being able to quickly move files off a target for analysis or upload tools when necessary is an important operational skill during penetration testing.

6. Defensive Insight

Security Improvements

1. Avoid exposing internal development utilities on production systems

   The web application on this system appeared to be a temporary script testing interface used for executing local PHP scripts. Development utilities like this should never be exposed on publicly accessible systems. These tools often assume trusted input and can introduce serious vulnerabilities when exposed to untrusted users. In this case, the testing interface directly allowed users to load scripts from the server, which ultimately led to a Local File Inclusion vulnerability.

2. Validate and sanitize all user-controlled file inputs

   The application accepted a user-controlled parameter that directly referenced files on the server:

   browse.php?file=<filename>
   

   Because the parameter was not properly validated, it allowed arbitrary file inclusion. Proper defenses should include:

   • Whitelisting allowed files

   • Rejecting absolute file paths

   • Restricting directory traversal

   • Avoiding dynamic file inclusion whenever possible

   Implementing strict input validation would have prevented attackers from requesting sensitive files such as /etc/passwd.

3. Sensitive files should never be stored in the web root

   The file pwdbackup.txt containing the encoded password was stored directly inside the web directory and could be accessed by anyone who discovered the path. Even though the password was encoded multiple times, encoding is not encryption and provides no real security.

   Sensitive data such as password backups or configuration files should never be placed inside publicly accessible directories.

4. Avoid storing credentials in reversible formats

   The password in this case was simply Base64 encoded multiple times, which provides no meaningful protection. Any attacker who recognizes the encoding can decode it quickly.

   Proper credential storage should involve:

   • Strong hashing algorithms such as bcrypt, scrypt, or Argon2

   • Salting hashes

   • Avoiding plaintext or reversible storage entirely

5. Restrict access to system logs and other sensitive files

   Because the application allowed arbitrary file inclusion, attackers could read server logs and other sensitive files. If log files are accessible through application functionality, they can be abused through techniques like log poisoning, which may lead to remote code execution.

   Applications should ensure log files and other sensitive system resources are never accessible through user-controlled file paths.

6. Restrict internal services to trusted users

   The VNC service running on ports 5801 and 5901 was bound only to localhost, which is good practice. However, once an attacker gains a foothold on the system, local-only services can still be abused if additional protections are not in place.

   Administrators should ensure that services such as VNC:

   • Require strong authentication

   • Do not run with unnecessary privileges (such as root)

   • Are protected with additional access controls where possible

7. Protect X Window authentication tokens

   The authentication cookie used by the Xvnc service was stored in a location accessible to a low-privileged user. Because this cookie acts as a trusted authentication token, anyone who obtains it can connect to the graphical session.

   Proper security practices should ensure that authentication tokens are protected with strict file permissions and are not accessible to unprivileged users.

8. Regular security audits and configuration reviews

   Several misconfigurations combined to create the full attack chain on this system. Regular security reviews of system configurations, file permissions, exposed services, and application behavior could have identified these weaknesses before they were exploited.

   Routine security auditing is essential for identifying issues such as:

   • Improper file permissions

   • Exposed development tools

   • Vulnerable web application functionality

   • Misconfigured services running with elevated privileges

Useful Commands

Below are some of the key commands used during enumeration, exploitation, and privilege escalation throughout the engagement.

Network Enumeration

Perform a service and version scan to identify open ports and services on the target.

nmap -sC -sV -p- <target-ip>

---

Identifying Users with Login Shells

After retrieving /etc/passwd through the LFI vulnerability, filtering the file helped identify users that actually have interactive shells.

cat user.txt | grep "sh$"

---

Inspecting Unknown Binary Data

The extracted file contained raw binary data which can be inspected using hexdump.

cat secret | hexdump -C

---

Enumerating Listening Services FreeBSD version

Checking for services bound to localhost can reveal hidden attack surfaces not visible during external scans.

netstat -an -p tcp

---

Identifying Running Processes FreeBSD version

This command helps identify which services are responsible for open ports.

ps -auwwx

---

Creating an SSH Tunnel

Because the VNC service was only accessible locally, an SSH tunnel was created to forward the port to the attacker machine.

ssh -L 5901:127.0.0.1:5901 charix@<target-ip>

---

Securely Copying Files from the Target

Files can be transferred from the target system to the attacker machine using scp.

scp charix@<target-ip>:/home/charix/secret.zip .