# OSCP Prep #10 
HTB Write-Up Poison

# 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.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/b1080adf-4cfe-4381-a6d6-0abfc4be7b23.png align="center")

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.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/5192ffa0-c670-4d74-a8ed-bb9c668bf343.png align="center")

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:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/c57d6828-85e8-4a1d-a869-1fdd57133714.png align="center")

One file immediately stood out:

```plaintext
pwdbackup.txt
```

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

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/61ef7a02-3916-4e34-9060-4f650512fdb5.png align="center")

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.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/a09136e8-9dea-4324-990f-fb4111b7af56.png align="center")

```plaintext
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:

```plaintext
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:

```plaintext
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**.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/205b2583-744c-49f1-8925-f20b021d35df.png align="center")

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:

```plaintext
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:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/219887cd-8a2b-4972-8204-d51ef42df8c3.png align="center")

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:

```plaintext
Charix!2#4%68&()
```

At this point I had a strong candidate credential pair:

```plaintext
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.

```plaintext
ssh charix@10.129.1.254
```

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

```plaintext
charix@Poison:~ %
```

The login banner confirmed the system was running:

```plaintext
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.

```plaintext
whoami
```

Output:

```plaintext
charix
```

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

```plaintext
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**.

```plaintext
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:

```plaintext
secret.zip
```

I extracted the archive to inspect its contents.

```plaintext
unzip secret.zip
```

The archive contained a file named:

```plaintext
secret
```

Running the `file` command revealed the following:

```plaintext
file secret
```

Output:

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

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

```plaintext
cat secret | hexdump -C
```

Output:

```plaintext
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.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/0eaa5778-a2cc-4288-b6fe-941a3b4a3187.png align="center")

```plaintext
netstat -an -p tcp
```

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

```plaintext
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.

```plaintext
ps -auwwx | grep vnc
```

This revealed the following process running under the **root** user:

```plaintext
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.

```plaintext
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.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/08a79c01-6c7e-461d-85d3-bd9279d38e57.png align="center")

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:
    
    ```plaintext
    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:
    
    ```plaintext
    /usr/local/etc/apache24/httpd.conf
    ```
    
    Reviewing this file revealed that the Apache access logs were stored at:
    
    ```plaintext
    /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:
    
    ```plaintext
    <?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:
    
    ```plaintext
    /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:
    
    ```plaintext
    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.

```plaintext
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.

```plaintext
cat user.txt | grep "sh$"
```

* * *

#### Inspecting Unknown Binary Data

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

```plaintext
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.

```plaintext
netstat -an -p tcp
```

* * *

#### Identifying Running Processes FreeBSD version

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

```plaintext
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.

```plaintext
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`.

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