Management - HackTheBox

I just solved Management from Hack the Box!

Management Machine Summary

Management is an easy-difficulty Linux machine on Hack The Box that focuses on web application exploitation, credential discovery, password reuse, and privilege escalation through a misconfigured sudo permission.

I began by performing an Nmap scan to identify the exposed SSH, HTTP, and HTTPS services. After configuring hostname resolution for management.htb, I enumerated the web application, discovered the sso.management.htb subdomain, and added it to my hosts file. Further investigation revealed an OpenAM authentication portal, which led me to research a potential remote code execution vulnerability.

I prepared a Python exploit, installed the Java Development Kit, and verified the Java environment before executing the exploit. After setting up a Netcat listener, I successfully obtained a reverse shell as the openam user.

I then enumerated the home directories, transferred LinPEAS to the target, and used it to investigate the operating system, running processes, and internal services. Further filesystem enumeration revealed a GLPI configuration directory containing database credentials. Using these credentials, I accessed the local MySQL database and discovered an LDAP configuration containing an encrypted service account password.

I created and transferred a PHP decryption script that used GLPI's built-in functionality to recover the LDAP password. Testing the recovered credential against SSH revealed that it was also valid for the local user owen. I authenticated as Owen, obtained an interactive SSH session, and retrieved the user flag.

Finally, I enumerated Owen's sudo permissions and discovered that rdiff-backup could be executed as root without a password. By exploiting its argument handling to bypass the intended path restriction, I copied the contents of /root to a writable directory and retrieved the root flag.

Management demonstrates how an initial web application compromise can lead to full machine compromise through exposed application credentials, password reuse, and an improperly restricted privileged command.

Protected Page

The first step in owning the Management machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:

Once the connection between my Kali Linux terminal and Hack the Box server has been established, I started the Management machine and I was assigned an IP address (10.129.26.248).

Nmap Enumeration

I started by running an Nmap scan against the target to identify open ports, detect service versions, and gather information about the underlying operating system.

The scan revealed three open TCP ports: 22 (SSH), 80 (HTTP), and 443 (HTTPS). SSH was running OpenSSH 9.6p1, while both web ports were served by nginx 1.24.0 on Ubuntu.

I noticed that port 80 redirected to HTTPS, and port 443 redirected to https://management.htb/. The SSL certificate also disclosed a wildcard domain, *.management.htb, suggesting that additional subdomains might exist.

Based on these findings, I identified the web application as my primary enumeration target and planned to investigate its virtual hosts and subdomains for additional attack surfaces.

Hostname Resolution

I added the discovered domain management.htb to my local /etc/hosts file, mapping it to the target IP address so I could access the web application using its intended hostname.

I authenticated with my sudo password to append the entry, and the command returned the mapping, confirming that it had been written successfully.

This allowed my machine to resolve management.htb locally without relying on DNS, ensuring I could access the application through its domain name for further enumeration.

Web Application Enumeration

I opened my browser and navigated to https://management.htb to investigate the web application.

The homepage revealed a managed IT services company offering infrastructure management, identity and access management, monitoring, and backup services.

I explored the available sections and noticed references to SSO, SAML, OAuth federation, and a unified identity broker, suggesting that authentication plays a significant role in the application.

I also identified a Client login button, which appeared to be a promising entry point for further investigation.

Finally, I discovered a contact form and the email address hello@management.htb, providing additional information that could be useful during enumeration.

Subdomain Discovery

I continued enumerating the web application by hovering over the Client login button to inspect its destination URL. The browser's status bar revealed that the button pointed to a previously undiscovered subdomain:

The sso prefix suggested that the application used a Single Sign-On (SSO) system to manage client authentication. I identified this subdomain as a potential entry point and decided to investigate it further for authentication-related vulnerabilities.

Subdomain Host Configuration

I added the newly discovered sso.management.htb subdomain to my local /etc/hosts file, mapping it to the target IP address.

The command successfully appended the entry and displayed the hostname mapping as confirmation. This allowed my machine to resolve the SSO subdomain locally without relying on DNS. With hostname resolution configured, I could now access the SSO application through my browser and continue enumerating its authentication functionality.

OpenAM Authentication Enumeration

I navigated to http://sso.management.htb in my browser and was redirected to the following HTTPS login endpoint:

The login page revealed that the SSO service was running OpenAM Community Edition, an identity and access management platform. I identified a login form requiring a username and password, confirming that the subdomain hosted an authentication portal. With the underlying technology identified, I decided to investigate OpenAM further, focusing on version disclosure and publicly known vulnerabilities that could provide a potential entry point.

OpenAM Vulnerability Research

I searched for publicly disclosed vulnerabilities affecting OpenAM and discovered a recent pre-authentication Remote Code Execution (RCE) vulnerability. The search results highlighted CVE-2026-33439, which reportedly involves Java deserialization through jato.clientSession.

I continued researching the vulnerability and discovered a publicly available proof-of-concept (PoC) exploit on GitHub:

The repository contained exploit code and documentation describing the vulnerability, making it a potential avenue for further investigation. I decided to examine the PoC and determine whether the target's OpenAM installation was vulnerable.

OpenAM Exploit Preparation

I created a Python script named cve-2026-33439.py using Nano and pasted the proof-of-concept exploit code into it.

I examined the script and found that it targeted OpenAM's jato.clientSession parameter through an insecure Java deserialization vulnerability. The exploit downloads the required Java dependencies, compiles a malicious Java class, and constructs a serialized payload designed to execute arbitrary system commands. 

It also probes several OpenAM endpoints before delivering the payload through GET or POST requests. With the exploit script prepared, I was ready to test whether the target's OpenAM installation was vulnerable to CVE-2026-33439.

Java Development Kit Preparation

I needed a Java Development Kit (JDK) to compile the Java payload used by the OpenAM exploit, so I started by refreshing my Kali Linux package repositories.

I cleared the cached packages, removed the existing package lists, and downloaded fresh repository metadata to ensure the latest available package information.

Next, I checked the available JDK versions using apt policy and confirmed that none of the queried packages were installed. The repositories offered OpenJDK 21 and OpenJDK 25, allowing me to select JDK 21 for the exploit's compilation requirements.

Java Development Kit Installation

I proceeded to install OpenJDK 21, which was required to compile and execute the Java components used by the OpenAM exploit.

The command downloaded approximately 129 MB of packages, including the Java Runtime Environment (JRE), JDK, and their headless dependencies. The installation completed successfully, and Kali Linux automatically configured the Java development tools through update-alternatives. With javac and the Java runtime installed, my environment was ready to compile the exploit's Java payload and proceed with testing.

Java Version Verification

I verified the installed Java runtime and compiler versions to ensure my environment was properly configured for the OpenAM exploit.

The output revealed that the Java runtime was using OpenJDK 25.0.3, while the Java compiler was running JDK 21.0.11-ea. This confirmed that both Java and javac were available, although they were using different versions. I identified this mismatch as a potential compatibility issue and needed to align both versions before compiling and executing the exploit payload.

OpenAM Exploit Execution

I executed the Python exploit against the OpenAM application, specifying the id command to test for remote code execution.

The script successfully downloaded six required Java dependencies and identified three accessible JATO endpoints, all returning HTTP 200. I observed that the exploit compiled the malicious Java class and generated a 4,290-character serialized payload.

The payload was delivered to all three endpoints, each returning HTTP 200, indicating that the requests were successfully processed at the HTTP level. However, the output did not confirm command execution, so I needed to verify the vulnerability through an out-of-band callback before concluding that the exploit was successful.

Netcat Listener Setup

I set up a Netcat listener on my attacking machine to receive an incoming reverse shell connection from the target.

I used rlwrap to provide command history and improved terminal interaction once a shell was established. The -l option enabled listening mode, while -v, -n, and -p enabled verbose output, disabled DNS resolution, and specified port 4444.

The output confirmed that Netcat was listening on port 4444, ready to receive a connection. With the listener running, I could proceed with delivering the reverse shell payload through the OpenAM exploit.

OpenAM Remote Code Execution – Initial Foothold

With my Netcat listener running on port 4444, I executed the OpenAM exploit again, replacing the previous id command with a Bash reverse shell payload.

The payload instructed the target to initiate a reverse shell connection to my attacking machine at 10.10.14.192 on port 4444. The script identified three accessible JATO endpoints and successfully compiled the malicious Java class containing my reverse shell command.

It then generated a 4,350-character serialized payload and delivered it to all three endpoints, each returning HTTP 200. Shortly afterward, I received an incoming connection on my Netcat listener.

The connection originated from the target IP address, confirming that the reverse shell payload had executed successfully. The openam@management:/$ prompt revealed that I had obtained a shell as the openam user.

Although Bash displayed terminal and job-control warnings, these did not prevent me from accessing the system. I had successfully established my initial foothold and could now begin enumerating the compromised machine for potential privilege escalation opportunities.

Home Directory Enumeration

After obtaining a reverse shell as the openam user, I navigated to the /home directory to identify other users on the system.

The output revealed a single user directory named owen, owned by the owen user and group. I noticed that the directory permissions were set to drwxr-x---, meaning only the owner and members of the owen group could access it.

Since I was operating as openam, I identified owen as a potential target for lateral movement and continued enumerating the system for a way to access this account.

LinPEAS Preparation for Privilege Escalation

I decided to use LinPEAS to automate local enumeration and identify potential privilege escalation opportunities on the compromised machine.

I downloaded the latest LinPEAS script from its official GitHub repository, and the HTTP 200 response confirmed that the download was successful. I verified that linpeas.sh existed in my working directory using ls -l.

Next, I started a Python HTTP server on port 8000 to make the script accessible to the target machine. With the server running, I was ready to transfer LinPEAS to the compromised host and begin local privilege escalation enumeration.

LinPEAS Transfer to Target

I navigated to the /tmp directory on the compromised machine, which provided a writable location for transferring the LinPEAS script.

I used wget to download the script from the Python HTTP server running on my attacking machine at 10.10.14.192:8000. The server returned HTTP 200, and the 1.1 MB file was successfully downloaded.

The output confirmed that linpeas.sh was saved in /tmp, making it available for local enumeration. With the script transferred, I was ready to execute LinPEAS and investigate potential privilege escalation vectors.

LinPEAS Enumeration - System Information and Active Services

After transferring LinPEAS to the target, I made the script executable and ran it as the openam user to identify potential privilege escalation opportunities.

The script started successfully and began collecting information about the operating system, running processes, environment variables, and network services.

I confirmed that the target was running Ubuntu 24.04.5 LTS, with Linux kernel version 6.8.0-139-generic. The enumeration also confirmed that my shell was running as openam, with UID 996 and GID 987.

I noticed that the environment variables revealed several important application paths, including /opt/openam and /opt/openam-tomcat. The JAVA_HOME variable pointed to /usr/lib/jvm/java-21-openjdk-amd64, confirming that the OpenAM service was using Java 21.

LinPEAS identified a Java process running under the openam account and listed numerous OpenAM libraries, including version 16.0.5. The process information also exposed OpenAM configuration directories, application logs, and an embedded directory service.

I then examined the active network services and discovered that MySQL was listening on 127.0.0.1:3306. Since MySQL was bound to the loopback interface, it was accessible locally but not directly exposed through that interface to external hosts.

I also identified a Tomcat service listening on 127.0.0.1:8080, along with several additional Java-related ports. These findings revealed internal services that had not appeared in my initial external Nmap scan. I decided to focus my next enumeration steps on the OpenAM configuration files, internal services, and potential database credentials to identify a possible path from the openam account to another user.

GLPI Configuration Enumeration

I continued enumerating the filesystem and discovered a GLPI configuration directory at /opt/glpi/config, which I investigated for potentially sensitive information.

The directory contained four files: config_db.php, glpicrypt.key, oauth.pem, and oauth.pub. I noticed that config_db.php was world-readable, making it a promising location to investigate for database credentials. The glpicrypt.key file was also world-readable, potentially exposing an application encryption key.

However, the OAuth key files were restricted to www-data, preventing my current openam account from reading them directly. I decided to examine the accessible configuration files for credentials or other sensitive information that could help me progress further.

Database Credential Discovery

I examined the world-readable config_db.php file to investigate whether it contained database credentials.

The configuration file revealed the MySQL username glpi, password 8rhu0L6Pw4Y7, and database name glpidb. I also confirmed that the database was configured to use 127.0.0.1, matching the internal MySQL service discovered during LinPEAS enumeration. Next, I navigated to the OpenAM configuration directory and listed its contents to identify additional sensitive files.

I discovered boot.json, .version, and several configuration directories, including ldif, openam, and opends. With the GLPI database credentials recovered, I had a potential route for further database enumeration while continuing to investigate OpenAM's configuration files.

GLPI LDAP Configuration Enumeration

I first checked the OpenAM version before using the recovered GLPI database credentials to investigate its LDAP authentication configuration.

The version file confirmed that OpenAM was running version 16.0.5. I successfully authenticated to the local MySQL database and retrieved an LDAP configuration entry named Management Directory. The entry identified sso.management.htb as the LDAP server, with the base DN dc=management,dc=htb and service account cn=svc-glpi,ou=services,dc=management,dc=htb.

I also discovered that the rootdn_passwd field contained an encrypted password, rather than a plaintext credential. Since I had previously identified the world-readable glpicrypt.key file, I decided to investigate whether it could be used to decrypt the stored LDAP service account password.

GLPI LDAP Password Decryption

After discovering the encrypted LDAP bind password in the GLPI database, I prepared a PHP script to decrypt it using GLPI's built-in functionality.

I created key_decrypt.php using nano and added the encrypted password recovered from the glpi_authldaps table. The script loads GLPI's dependencies and GLPIKey class, using the configuration directory containing the application's encryption key.

I then instantiated GLPIKey and passed the encrypted value to its decrypt() method. The script was now ready to run on the target, where the GLPI installation and encryption key were available, to attempt recovery of the LDAP service account password.

GLPI Decryption Script Transfer

I transferred the PHP decryption script to the compromised machine so I could execute it using the target's GLPI installation and encryption key.

I navigated to /tmp and used wget to retrieve key_decrypt.php from the Python HTTP server running on my attacking machine. The server returned an HTTP 200 OK response, confirming that the request was successful.

The output showed that the 382-byte script was downloaded and saved as /tmp/key_decrypt.php. With the script successfully transferred, I was ready to execute it and attempt to recover the LDAP service account password.

LDAP Service Account Password Recovery

After transferring the decryption script to the target, I executed it using PHP to recover the encrypted LDAP bind password.

The script successfully decrypted the password using GLPI's built-in GLPIKey functionality and the application's encryption key. The output revealed the plaintext password: WpczC40GhTbk.

I associated this credential with the previously identified LDAP service account, cn=svc-glpi,ou=services,dc=management,dc=htb. With the LDAP bind credentials recovered, I could proceed to authenticate against the directory service and enumerate its users and other accessible information.

SSH Credential Reuse and User Access

After recovering the LDAP service account password, I tested whether the same credential could authenticate as the local user owen.

I used NetExec to test the recovered password against the SSH service on management.htb. The output confirmed successful authentication with the credentials owen:WpczC40GhTbk. NetExec also reported Pwn3d! and Linux - Shell access!, indicating that the account could access the system through SSH.

This confirmed that the recovered password was also valid for owen, providing a path to move from the openam account to a regular user account. With SSH access verified, I could log in as owen and continue enumerating the system for further privilege escalation opportunities.

SSH Access as Owen

After confirming that the recovered password worked for owen, I initiated an SSH connection to obtain an interactive shell.

I accepted the server's ED25519 host key when prompted, adding it to my local known_hosts file. I then entered the recovered password, WpczC40GhTbk, and successfully authenticated as owen. The SSH banner confirmed that the target was running Ubuntu 24.04.5 LTS with kernel version 6.8.0-139-generic.

The owen@management shell prompt confirmed that I had obtained an interactive session as the user. With access established, I could begin enumerating Owen's home directory and checking for further privilege escalation opportunities.

User Flag Retrieval

After gaining SSH access as owen, I verified my identity and enumerated the contents of the user's home directory.

The whoami command confirmed that I was logged in as owen, while id showed UID 1000 and GID 1000. I listed the home directory and discovered the user.txt file. I then read the file and successfully retrieved the user flag: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.

This confirmed that I had completed the user-level objective. With the user flag obtained, I could proceed to enumerate the system for a path to root privileges.

Sudo Privilege Enumeration

After retrieving the user flag, I checked Owen's sudo permissions to identify potential privilege escalation opportunities.

The output revealed that I could execute /usr/bin/rdiff-backup as root without providing a password. I noticed that the permitted command included --server, --restrict-path /opt/backup, and --restrict-mode read-only.

These options appeared to limit the command to read-only operations within /opt/backup, but the trailing wildcard allowed additional arguments. I identified rdiff-backup as a potential privilege escalation vector and decided to investigate whether its argument handling could bypass the intended restrictions.

This sudo configuration provided a promising lead for obtaining root privileges.

Privilege Escalation via rdiff-backup

After identifying the sudo misconfiguration, I exploited rdiff-backup to access files outside the intended /opt/backup directory.

I used --remote-schema to define a custom server command that executed rdiff-backup with root privileges. By appending another --restrict-path argument, I bypassed the intended path restriction and selected /root as the backup source.

The output confirmed that rdiff-backup started mirroring /root into /tmp/rootbak. I then read the copied root.txt file and successfully retrieved the root flag: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.

This completed the root-level objective by exploiting the sudo configuration, without requiring an interactive root shell.

Keywords:

HackTheBox - BlockSynergy - Insane  - Linux Machine Complete HTB Walkthrough Season 11 Hack the Box

Management - HackTheBox

management.htb

sso.management.htb

Management - Season 11 Hack the Box Walkthrough

management - hack the box writeup

HackTheBox Season 11 Management Hack the Box Machine Complete Walkthrough

management machine htb: r/hackthebox

Management Walkthrough: Beginner's Writeup from HackTheBox

Management HTB (Easy) Linux Season 11 Machine Complete Writeup

GitHub HackTheBox-Writeups-Walkthroughs HTB Management Machine challenge write-up

Hack The Box - Season 11 HTB Management Writeup - Easy - Linux Machine

HTB Writeup - Management

I just solved Management from Hack the Box!

HacktheBox Write up - management

Management HTB Walkthrough

Hack The Box - HTB DarkZeroReturns - Hard - Windows Machine

HTB Writeup - BlockSynergy

Hack The Box - HTB BlockSynergy Writeup

blocksynergy.htb

BlockSynergy HTB Walkthrough

BlockSynergy Hack the Box Writeup

I just solved BlockSynergy from Hack the Box

BlockSynergy Hack the Box Walkthrough

Mastering BlockSynergy from Hack the Box Beginner's Guide

blocksynergy htb - complete write up Linux machine solution

HTB Season 11 Writeups - BlockSynergy Complete Machine Walkthrough

TrustFall.htb

TrustFall HTB Walkthrough

TrustFall HTB Writeup

TrustFall - HackTheBox

I just solved TrustFall from Hack the Box

HackTheBox - TrustFall Season 11 Complete HTB Machine Walkthrough & Solutions

trustfall walkthrough - insane - htb machine - complete writeup - season 11 hackthebox solution

Scaffold HTB Writeup

Scaffold HTB Writeup - HackTheBox Season 11 Machine Complete Walkthrough

scaffold.htb

Scaffold Hack the Box Write up

I just solved Scaffold from Hack the Box

Scaffold HTB Walkthrough

Scaffold Hack the Box Walkthrough