DevHub HTB
DEVHUB Box Overview DevHub is a Linux machine that focuses on exploiting insecure developer tooling and internal management services. The attack begins with an exposed MCPJam Inspector instance vulnerable to remote code execution, providing initial access as the mcp-dev user. After gaining a foothold, process enumeration reveals a JupyterLab instance running under the analyst account with its authentication token exposed in the process arguments. By leveraging SSH port forwarding and the leaked token, it is possible to access JupyterLab and pivot into the analyst user's context. The final privilege escalation involves analyzing an internally developed management service called OPSMCP. Reviewing its source code reveals hidden administrative functionality protected only by a hardcoded API key. Abusing this functionality allows the extraction of the root user's SSH private key, ultimately leading to full compromise of the system. DevHub is a great example of how exposed development tools, leaked credentials, insecure API design, and hidden administrative functionality can be chained together to achieve root access. Enumeration Nmap Scanning Running a full port Nmap scan against the target: Nmap Scan Analysis From the Nmap scan, we can identify the following services: | Port | Service | |------|----------| | 22 | SSH | | 80 | HTTP | | 6274 | Unknown | Some important observations: The target is running Ubuntu Linux. SSH is exposed and may provide remote access if valid credentials are obtained. Port 80 is running an Nginx web server. Port 6274 appears to be hosting an HTTP-based service that responds with JSON data. The hostname devhub.htb was identified during enumeration. Adding Hostname to /etc/hosts Since the hostname was discovered during enumeration, I added it to my hosts file. Initial Enumeration At this stage, the most interesting services are: Port 80 (Web Application) Port 6274 (Unknown Service) Browsing port 6274 revealed the following application: Screenshot 2026-06-04 at 15-43-11 The application is running MCPJam Inspector v1.4.2. After researching the version, I found that it is vulnerable to Remote Code Execution (RCE). Foothold - MCPJam RCE A public proof-of-concept is available: Cloning the repository: Checking the exploit usage: Setting Up a Listener Before running the exploit, start a Netcat listener: Exploiting MCPJam Executing the exploit: Although the exploit timed out while waiting for a response, the reverse shell was successfully executed. --- Obtaining a Shell Checking the listener: A reverse shell was obtained as the mcp-dev user. Enumerating the /home directory: We can see another user named analyst, but we currently do not have permission to access that account. Stable Shell via SSH Key Injection The reverse shell was not very stable, so I decided to add my SSH public key to the mcp-dev user's authorized_keys file. On Kali, generate an SSH key pair (if you do not already have one): In the reverse shell on the target: With the key added, SSH access can be established from Kali. SSH as mcp-dev Connecting to the target: Successfully obtained a stable SSH session as the mcp-dev user. Privilege Escalation to Analyst Enumeration While enumerating running processes, I noticed an interesting process owned by the analyst user: The process immediately stood out because it exposed a Jupyter authentication token directly in the process arguments: Let's take a closer look at the command: From the command line arguments we can determine: JupyterLab is running locally on port 8888 Authentication is performed using the exposed token No password is configured The service is running as the analyst user While enumerating further, I also noticed another interesting file: Since the file is owned by analyst, gaining access to that account may reveal a path to root later in the attack chain. Lateral Movement to analyst Since JupyterLab was only listening on localhost, I used SSH local port forwarding to access it from my browser. With the tunnel established, I browsed to: JupyterLab presented a login page requesting a token. Using the token recovered from the process list: Screenshot 2026-06-04 at 17-58-53 After authenticating successfully, I was prompted to set a password. Screenshot 2026-06-04 at 18-00-01 Once authenticated, I gained full access to the JupyterLab instance running as the analyst user. Obtaining a Shell as Analyst Inside JupyterLab, I opened a new terminal session. Running: This confirms that the terminal is running with the privileges of the analyst user. At this point, we have successfully pivoted from mcp-dev to analyst. User Flag Privilege Escalation to Root During the enumeration phase as the analyst user, I noticed an interesting process running as root: The process was executing: Let's inspect the source code. Analyzing OPSMCP Viewing the file: While reviewing the source code, several interesting findings stood out: Hardcoded API Key Hidden Administrative Tools Dangerous Credential Dump Functionality The source code revealed a hidden tool named: When called with: the application reads: and returns the contents. At this point we have everything needed to retrieve the root SSH key. --- Exploiting the Hidden Tool Using the API key recovered from the source code, I called the hidden endpoint: The server returned the root user's private SSH key: Success! We now have access to the root user's private SSH key. Formatting the SSH Key Save the key to a file: Since the key is returned with escaped newline characters (\n), they must be converted back into real newlines. One way to do this is: Screenshot 2026-06-04 at 18-08-57 Verify that the key looks like a valid OpenSSH private key. Next, set the correct permissions: SSH as root Using the recovered private key: Verifying access: Successfully obtained a shell as the root user. Root Flag Root obtained successfully. Attack Path Final Thoughts DevHub was a fun and realistic machine that showcased how small security oversights can quickly snowball into a full system compromise. The attack chain started with an exposed and vulnerable MCPJam instance, followed by credential disclosure through process enumeration, and ended with the abuse of an internally developed management service that exposed highly sensitive functionality. What made this box particularly interesting was that every step felt realistic. There were no kernel exploits or complex privilege escalation tricks—just insecure configurations, leaked secrets, and poor access controls that could easily be overlooked in a real-world environment. Overall, DevHub highlights the importance of securing development tools, protecting authentication tokens, and regularly auditing internal services for hidden functionality and hardcoded credentials. Thanks for reading, and I'll see you in the next writeup!