About the Machine
CodePartTwo is an easy-difficulty Linux machine that focuses on web application exploitation, dependency analysis, and basic privilege escalation techniques. The box begins with enumeration of a Python-based Flask application running on a non-standard HTTP port, where source code disclosure plays a key role in identifying the attack surface.
The initial foothold is achieved by exploiting an insecure use of the js2py library, vulnerable to CVE-2024-28397, allowing sandbox escape and remote code execution through user-supplied JavaScript. This vulnerability highlights the risks of executing untrusted code within improperly sandboxed environments.
Post-exploitation involves database enumeration and weak credential storage, where unsalted MD5 password hashes are easily cracked and reused to gain SSH access as a legitimate system user. The final stage demonstrates a classic sudo misconfiguration, where unrestricted access to a backup utility (npbackup-cli) allows attackers to read sensitive root-owned files and escalate privileges.
Overall, CodePartTwo is an excellent introductory machine for learning real-world web exploitation chains, credential reuse, and misconfigured sudo privileges, reinforcing the importance of secure dependency management and least-privilege enforcement in Linux environments.
The first step in owning CodePartTwo 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:
Initial Enumeration
I began by performing a full service and version scan against the target using Nmap to identify open ports, running services, and operating system details:
The Nmap scan confirmed that the host codetwo.htb was reachable and online, and out of the 1000 TCP ports scanned, only two ports were open, which immediately narrowed the attack surface.
Port 22/tcp was running OpenSSH 8.2p1 on Ubuntu. This indicates that SSH access is available, but without valid credentials it is not immediately exploitable. However, the SSH version is still useful for later stages, especially if credentials or private keys are discovered during enumeration.
More interestingly, port 8000/tcp was open and hosting an HTTP service powered by Gunicorn 20.0.4, a Python WSGI server commonly used with Flask or Django applications. The page title, “Welcome to CodePartTwo”, strongly suggests that this is a custom web application and likely the primary attack vector.
Mapping Target's IP Address to Hostname
Before interacting further with the target, I needed to ensure that my system could properly resolve its hostname. During the Nmap scan, the machine identified itself as codetwo.htb, which is not resolvable by default outside the Hack The Box environment.
To fix this, I manually mapped the target’s IP address to its hostname by appending an entry to the local /etc/hosts file:
This step allows my browser and command-line tools to resolve codetwo.htb correctly, which is especially important for web applications that rely on virtual hosts or hostname-based routing. Using sudo tee -a ensures the entry is added with the required privileges while preserving existing host mappings.
With hostname resolution in place, I could now interact with the web service on port 8000 using http://codetwo.htb, avoiding potential issues caused by accessing the application directly via its IP address. This setup step cleared the way for proper web enumeration in the next phase of the attack.
Web Enumeration
After setting up hostname resolution, I navigated to the target in my browser. Visiting http://10.10.11.82 automatically redirected me to http://codetwo.htb, confirming that the application relies on hostname-based routing rather than direct IP access.
The landing page presented a clean web interface branded “CodePartTwo”, advertising itself as an open-source platform for writing and running JavaScript code. The navigation was minimal, with three clear options: Login, Register, and Download App. Since authentication endpoints often become relevant later, I first focused on the Download App feature, which frequently exposes client-side logic or source code in CTF challenges.
Clicking Download App triggered a direct file download, returning an archive named app.zip. This immediately stood out, as challenges rarely hand out application source code unless it is meant to be analyzed. I extracted the archive locally and found two files: app.py and requirements.txt, indicating a Python-based web application.
Inspecting requirements.txt revealed the following dependencies:
flask==3.0.3- flask-sqlalchemy==3.1.1
- js2py==0.74
The presence of js2py was particularly interesting. This library allows JavaScript code to be executed directly inside a Python environment. In CTF contexts, this is often a red flag especially if any part of the JavaScript execution is influenced by user input because it can lead to sandbox escapes or arbitrary code execution if not handled correctly.
With this in mind, I shifted focus to vulnerability research. A quick search confirmed that js2py version 0.74 is affected by CVE-2024-28397, a known vulnerability that allows unsafe JavaScript execution and potential sandbox escape when the library is used improperly. This aligned perfectly with the application’s purpose of running JavaScript code and strongly suggested an intentional attack surface.
To validate exploitability, I also found a publicly available proof-of-concept for this vulnerability, which demonstrated how malicious JavaScript could break out of the intended execution context.
Cloning the Public PoC Repository
After identifying CVE-2024-28397 as a promising attack vector, the next step was to understand how the vulnerability could be exploited in practice. Rather than attempting to build an exploit from scratch, I looked for existing public proof-of-concepts to confirm exploitability and speed up testing.
I cloned a public PoC repository for the vulnerability directly from GitHub:
The repository cloned successfully, confirming that the exploit was lightweight and self-contained. Navigating into the project directory revealed only three files: exploit.py, README.md, and LICENSE.
The presence of exploit.py was particularly encouraging, as it indicated a ready-to-use demonstration of the js2py sandbox escape. At this stage, the plan was to inspect the exploit code and compare its execution flow with how js2py was used inside the CodePartTwo application. If user-controlled input reached the vulnerable execution path, this PoC could likely be adapted to achieve code execution on the target.
With a working proof-of-concept for CVE-2024-28397, I moved on to exploitation. To catch a reverse shell from the target, I first started a Netcat listener on my attacking machine, listening on port 4444:
With the listener ready, I executed the exploit script from the cloned PoC repository, pointing it at the vulnerable endpoint exposed by the application (/run_code) and supplying my own IP address as the callback host:
The exploit automatically generated a malicious JavaScript payload, embedded a Base64-encoded Bash reverse shell, and sent it to the target for execution via the vulnerable js2py sandbox. Although the HTTP response returned a harmless-looking error message, this was a good sign - the application had processed the payload rather than rejecting it.
Moments later, the Netcat listener lit up with an incoming connection from the target, confirming successful remote code execution.
The shell landed as the app user (UID 1001), which aligns with the service account running the Flask application. To make the shell more usable, I upgraded it to a fully interactive TTY using Python’s pty module:
From there, I confirmed the available local users and verified that direct access to other home directories, such as marco, was restricted.
Since this was a Flask application, I focused on common application data locations. Navigating to /home/app/app/instance, I found a SQLite database named users.db, which appeared to store application credentials. Inspecting the database revealed two tables: user and code_snippet.
Querying the user table exposed stored usernames and password hashes for both the marco and app accounts.
At this point, I had achieved initial foothold on the system and obtained credential material that could potentially be cracked or reused for lateral movement or privilege escalation.
Cracking the Hash Password
After dumping the contents of the users.db database, I recovered a password hash associated with the marco user:
Based on its length and format, the hash strongly resembled an MD5 digest. Since MD5 is fast and widely broken using precomputed wordlists, I opted to try a quick online crack before resorting to offline brute-forcing.
I copied the hash into CrackStation, a public hash-cracking service backed by large rainbow tables and wordlists. Almost instantly, the hash was successfully resolved, revealing the plaintext password:
This confirmed that the application was storing unsalted MD5 hashes, a weak and insecure practice that makes credential recovery trivial once database access is obtained. With valid credentials for the marco account now in hand, I could attempt lateral movement either by switching users locally or reusing the password for SSH access.
SSH'ing into User Marco
With the plaintext credentials recovered, I attempted to reuse them for direct system access. Using the cracked password sweetangelbabylove, I initiated an SSH connection as the marco user:
On the first connection attempt, SSH prompted me to verify the host’s authenticity, which is expected when connecting to a system for the first time. After accepting the host key, the login succeeded and dropped me into an interactive shell on the target machine.
Once logged in as marco, I listed the contents of the home directory and immediately spotted the standard CTF artifact: user.txt. Reading the file revealed the user flag, confirming successful lateral movement from the low-privileged app user to a real system user.
Hurray!!! I got the user flag
At this stage, I had completed the user-level compromise of the machine. With SSH access as marco established and the user flag secured, the next objective was clear: investigate the contents of the home directory, particularly the backups folder and configuration files for clues that could lead to privilege escalation and full root access
Privilege Esclation
With user access secured, I moved on to privilege escalation. The first step was to check whether the marco user had any elevated privileges configured via sudo. Running sudo -l revealed a critical misconfiguration: marco is allowed to execute /usr/local/bin/npbackup-cli as root without providing a password.
This immediately stood out as a strong escalation vector. npbackup-cli is a backup utility, and tools that run as root and operate on the filesystem often provide ways to read or manipulate sensitive files if not properly restricted.
I noticed that marco’s home directory already contained an npbackup.conf file, so I copied it to a new configuration file and modified it locally. The goal was to see how much control the configuration file provided over backup behavior when the tool was executed as root. I ran:
Running nano test.conf command opened the notepad editor and I changed the directory /home/app/app to /root (make sure to edit this before running the command: sudo npbackup-cli -c test.conf -b -f)
After editing the configuration, I ran npbackup-cli using sudo, explicitly pointing it to my modified config file. The output confirmed that the backup process was running as root and, more importantly, that it was attempting to back up the /root directory. Even though the backup process reported some warnings and ultimately failed due to size constraints, this confirmed that the tool had unrestricted read access to root-owned files.
At this point, exploitation became straightforward. The npbackup-cli binary provides a --dump option, which allows individual files from the backup source to be output directly. Since the tool was running as root, I used it to dump the contents of /root/root.txt.
Executing the command immediately returned the root flag, confirming full privilege escalation and complete compromise of the system.
This final step demonstrated how a seemingly harmless NOPASSWD sudo rule for a backup utility can be abused to gain root access when configuration files and file paths are fully attacker-controlled.
Hurray!!! I got the root flag
With that, the machine was officially pwned!
If you enjoy reading my walkthrough, do not forget to like, comment, and subscribe to my YouTube channel and also connect with me on LinkedIn. Also, don't forget to turn on post notification on my YouTube channel and Medium to get notification as soon as I write.
Subscribe to my YouTube channel and Follow me on: LinkedIn | Medium | Twitter | Boltech Twitter | Buy Me a Coffee
Keywords:
CodePartTwo Hack the Box Writeup
CodePartTwo Hack the Box Machine Writeup
CodePartTwo Hack the Box Walkthrough
CodePartTwo Hack the Box Machine Walkthrough
CodePartTwo HTB Writeup
CodePartTwo HTB Walkthrough
CodePartTwo HTB Machine Walkthrough
CodePartTwo HTB Machine Writeup
CodePartTwo Hack the Box HTB Machine Walkthrough Writeup
CodePartTwo HTB Solution
CodePartTwo Hack the Box Solution
CodePartTwo Hack the Box Complete Walkthrough
CodePartTwo Hack the Box Complete Writeup
CodePartTwo Hack the Box Complete Solution
CodePartTwo htb write up
HackTheBox CodePartTwo Writeup
HTB CodePartTwo Writeup
HackTheBox CodePartTwo Writeup
HackTheBox - CodePartTwo (Writeup)
HTB Writeups - CodePartTwo
HackTheBox CodePartTwo Writeup
CodePartTwo | HTB Writeup | Linux
CodePartTwo htb
HTB - CodePartTwo Writeup
Owned CodePartTwo from Hack The Box
Hack The Box - HTB CodePartTwo Writeup
HTB CodePartTwo Detailed Writeup English
HackTheBox | CodePartTwo HackTheBox · HackTheBox | MonitorsFour
CodePartTwo HTB Writeup | HacktheBox | Season 9
HTB Writeup - CodePartTwo
Write-ups CodePartTwo Category Posts | Hack The Box Blog
CodePartTwo - Hack the Box - Walkthrough
CodePartTwo - HTB - Walkthrough
CodePartTwo - Hack the Box - Writeup
0 Comments