- Published on
CodePartTwo
- Authors

- Name
- Hassaan Ali Bukhari
- @B3TA_BLOCKER
CodePartTwo Machine (HackTheBox) — Step-by-Step Walkthrough

Machine info:
| IP Address | Difficulty | Points | Operating System |
|---|---|---|---|
| 10.10.11.82 | Easy | 20 | Linux |
Pinging:
The target machine is inside my local network, now I can move forward with network scanning to discover services, or open ports in the same network.
After scanning, I can continue with enumeration (collecting detailed information about the system and services) and then attempt privilege escalation to gain full **root access**
Nmap Scan:
Port 22 (SSH) → Keep in mind for later privilege escalation or login once creds are found.- **
Port 1234**→ Looks restricted, may require deeper probing. Port 8000→ Main focus now — web application likely vulnerable.
Port 8000:

The first step after finding a web service is to browse the website normally, just like an everyday user.
While doing this, I also keep Burp Suite running in the background to capture all the requests and responses. This helps me spot anything unusual or sensitive (like hidden parameters, tokens, or errors) that might give me leads for further enumeration.
On this site, I noticed there are Register and Login buttons.
So, I created a new account by registering, and then logged in to see how the application behaves and what features are available.


After logging in, I was presented with a code editor interface, very similar to the one from the previous HackTheBox machine “Code”.
This editor is a JavaScript editor instead of Python like before.
My first step is to test the editor and see what kind of code execution it allows. I’m also assuming there will be filters or restrictions in place (just like in the earlier machine) to prevent direct exploitation.
After trying many approaches and searching extensively, I initially focused on bypassing JavaScript filters. Most of the guides I found were about **web-based JavaScript injection**, which wasn’t applicable here.
In this challenge, the goal is to execute code directly in the JavaScript editor, which is a different scenario than typical JS injection on web pages.
After struggling for a while, I came across John Hammond’s video on escaping JavaScript sandboxes, which provided the correct approach for this type of environment.
Next, I decided to download the application as a ZIP file to inspect its **source code and structure**.

Inside the code, particularly in app.py, I noticed it was using the js2py library. This library allows running JavaScript code from Python.

I then looked for possible vulnerabilities or existing exploits. I found a CVE related to js2py, but many proof-of-concept scripts didn’t work for this setup.
Finally, I came across a GitHub repository with a working method for this type of exploitation. Using that approach, I inserted my reverse shell into the code editor, executed it, and successfully got a shell on the target machine.
https://github.com/waleed-hassan569/CVE-2024-28397-command-execution-poc/blob/main/payload.js
Script:

Reverse Shell
I executed the reverse shell, and it worked successfully. This gave me a shell on the target machine.

Make the Shell Stable:

I checked the shell I got, but it had very limited access and didn’t contain anything useful.
To progress, I need to migrate to another user with more privileges or useful files.
While exploring the system, I found a home directory for a user named marco, which could be the next target.
I wanted to get the password for the marco user.
Since I had previously downloaded the application and was familiar with its file structure, I knew where to look.
I went directly to the instance directory and found a file called user.db.
I then checked this database file to see if it contained any **user information or credentials**.
marco’s hash : 649c9d65a206a75f5abe509fe128bce5

password : sweetangelbabylove
SSH login
User Flag:
User Flag : ab17d77653f9d09b9c693554b26eaa4b
Root Flag:

It has npbackup-cli installed, which is a command-line backup tool. It functions similarly to other backup utilities like restic, allowing users to create, manage, and restore backups of directories and files.
In this scenario, since the marco have sudo privileges on npbackup-cli, it’s possible to use it to read or back up files that are normally restricted, including root-owned files.
This means I can potentially use npbackup-cli to back up the root directory and extract sensitive files, such as root.txt, to obtain the root flag — effectively achieving privilege escalation.
I didn’t have the permissions to directly edit the original config file for npbackup-cli.
So instead, I:
- Copied the content of the original config file.
- Created a new file called
my.conf. - Pasted the copied content into this new file.
This allowed me to modify the backup path (e.g., to /root) without needing direct access to the original configuration file.

In the npbackup-cli configuration file, I modified the backup path to point to /root.
This way, when the backup command is run, it will attempt to back up the root directory, including sensitive files like root.txt, which contains the root flag.

Root Flag : 4aff940b07fccd30e5972c5ba9075f6a