TryHackMe Wrong Path Walkthrough: Command Injection and PATH Hijacking
TryHackMe Wrong Path Walkthrough covers a Linux Boot2Root challenge built around an internal HelpDesk portal. The room combines web enumeration, command injection, password-hash cracking, SSH key recovery, credential reuse, and Linux privilege escalation through PATH hijacking.
What makes Wrong Path interesting is that the most obvious attack surface isn’t necessarily the correct one. The challenge rewards continued enumeration and demonstrates how several relatively small security mistakes can be chained together into a complete system compromise
Note: Flags, passwords, IP addresses, and challenge answers have intentionally been removed from this walkthrough.
TryHackMe Wrong Path Attack Path
The overall attack chain looks like this:
Web Enumeration
↓
Apparent LFI
↓
Red Herring
↓
Hidden PHP Endpoint
↓
Command Injection
↓
www-data
↓
Backup Enumeration
↓
Legacy Password Hash
↓
Password Cracking
↓
Encrypted SSH Private Key
↓
SSH as helpdesk
↓
User Flag
↓
Sudo Enumeration
↓
Vulnerable Backup Script
↓
PATH Hijacking
↓
Root
The challenge covers several different areas without making any single stage unnecessarily complicated.
Initial Enumeration
As usual, I started with an Nmap scan:
nmap -sC-sV $IP
The scan revealed the services available on the target, with the web server immediately becoming an interesting place to begin enumeration.
Opening the website revealed an internal HelpDesk portal.
While browsing the application, I noticed that navigation was controlled using a page parameter.
That immediately looked interesting because parameters that control which page or file gets loaded are often worth testing for Local File Inclusion or path traversal.
After several tests, however, the application appeared to restrict which pages could actually be loaded.
This was my first important lesson from TryHackMe Wrong Path: don’t develop tunnel vision around the first thing that looks vulnerable.
The page parameter looked promising, but it wasn’t the way forward.
Enumerating the Web Application
I returned to enumeration.
Because the application was running PHP, I wanted my content discovery scan to specifically test for PHP files.
Using Gobuster:
gobuster dir -u http://$IP \
-w /usr/share/wordlists/dirb/common.txt \
-x php
The important addition here is:
-x php
Without specifying the PHP extension, my initial Gobuster scan didn’t discover the endpoint I needed.
With PHP extensions enabled, another application endpoint appeared:
/diagnostics.php
This was a useful reminder that directory enumeration tools only test what we tell them to test. A clean Gobuster result doesn’t necessarily mean there is nothing else to find.
Investigating the Diagnostics Utility
The newly discovered page contained a network diagnostic utility.
It accepted a hostname or IP address and returned ping results.
Testing:
127.0.0.1
produced exactly what you’d expect from a normal ping command.
That raised an important question:
Was the application passing my input directly to an operating-system command?
I tested whether shell metacharacters could be used to append another command:
127.0.0.1; id
The response included the execution context of the web server.
At this point, I had confirmed OS command injection.
Command Injection to Remote Code Execution
The vulnerability existed because user-controlled input was ultimately being passed to a system command without sufficient validation or sanitization.
Additional commands could be used to understand the environment:
127.0.0.1; whoami
and:
127.0.0.1; ls -la /
The commands were executing under the web server’s account.
Although it was possible to continue enumeration through the browser, an interactive shell would make post-exploitation enumeration considerably easier.
I started a Netcat listener on my attacking machine:
nc -lvnp 4444
I then used the command-injection vulnerability to establish a reverse connection from the target.
Once connected, I verified my context:
whoami
id
pwd
I now had an interactive foothold as the web-service account.
Linux Post-Exploitation Enumeration
With a shell established, I began normal Linux filesystem enumeration.
Some basic commands included:
ls -la /
ls -la /home
ls -la /opt
Searching /opt proved particularly useful:
find /opt -type f 2>/dev/null
This revealed backup artifacts associated with the HelpDesk application.
Two files were especially interesting:
migrate_users.sh.bak
helpdesk_id_rsa.bak
The first appeared to be a forgotten user-migration backup.
Finding a Legacy Password Hash
Examining the migration backup revealed legacy authentication information, including a password hash.
The hash began with:
$6$
This identifies a Unix SHA-512 crypt password hash.
Rather than attempting to crack anything directly on the target, I copied the hash to my attacking machine and saved it:
nano hash.txt
I then used John the Ripper with Rockyou.txt:
john --format=sha512crypt \
--wordlist=/usr/share/wordlists/rockyou.txt \
hash.txt
The password was successfully recovered.
I won’t include the recovered password here, but recovering it did not immediately provide access to the HelpDesk account.
That meant the password was another piece of the puzzle rather than the complete answer.
Discovering the SSH Private Key
The second backup artifact was:
helpdesk_id_rsa.bak
Examining it revealed an OpenSSH private key.
I copied the complete private key to my attacking machine and saved it as:
helpdesk_id_rsa
OpenSSH requires restrictive permissions on private keys:
chmod600 helpdesk_id_rsa
Without that, SSH may refuse to use the key with an error such as:
Load key "helpdesk_id_rsa": bad permissions
I then attempted authentication:
ssh -i helpdesk_id_rsa helpdesk@$IP
The key was encrypted and required a passphrase.
This was where the previous discovery became important.
The legacy credential recovered from the migration backup had been reused as the SSH private-key passphrase.
Using that information successfully unlocked the key and provided SSH access to the helpdesk account.
Obtaining the User Flag
After authenticating through SSH, I verified my new context:
whoami
id
I then enumerated the HelpDesk user’s home directory:
ls -la ~
The first flag was located within the user’s home directory.
The actual flag is intentionally omitted from this walkthrough.
At this stage, the attack had progressed from an externally accessible web application to authenticated access as a legitimate Linux user.
The remaining objective was privilege escalation.
Linux Privilege Escalation Enumeration
One of my first privilege-escalation checks was:
sudo -l
This revealed that the HelpDesk account could execute a particular backup utility as root without providing a password.
The interesting program was located at:
/usr/local/bin/helpdesk-backup
Whenever a user can execute something with elevated privileges, the next step should be understanding exactly what that program does.
I inspected it:
cat /usr/local/bin/helpdesk-backup
The script created an archive using the tar command.
The important detail was that the script called:
tar
instead of explicitly calling:
/usr/bin/tar
That difference created the final privilege-escalation opportunity.
Understanding PATH Hijacking
When Linux encounters a command such as:
tar
it searches directories listed in the $PATH environment variable until it finds an executable named tar.
You can inspect the current PATH with:
echo $PATH
If an attacker can place a writable directory before the legitimate system directories, they may be able to provide their own executable named tar.
For example:
mkdir -p ~/bin
export PATH=$HOME/bin:$PATH
Now:
echo $PATH
shows the attacker-controlled directory first.
The vulnerable root backup script trusts PATH instead of explicitly requesting /usr/bin/tar.
That creates a PATH hijacking vulnerability.
Confirming Root Execution
To test the vulnerability, I created my own executable named:
tar
inside the attacker-controlled directory.
A harmless proof of concept can be used to demonstrate the vulnerability:
cat > ~/bin/tar <<'EOF'
#!/bin/bash
id > /tmp/root-proof
EOF
Then:
chmod+x ~/bin/tar
I executed the permitted backup utility:
sudo /usr/local/bin/helpdesk-backup
Finally:
cat /tmp/root-proof
The resulting output showed that the attacker-controlled program had executed with UID 0.
That confirmed successful arbitrary command execution as root.
Using the same primitive, the final root-level objective could be completed and the second flag recovered.
The root flag itself is intentionally omitted.
Why the PATH Hijacking Vulnerability Works
The vulnerable backup script effectively trusts the environment to locate an important executable.
Instead of:
tar -czf backup.tar.gz /some/directory
a privileged script should use an absolute executable path:
/usr/bin/tar -czf backup.tar.gz /some/directory
Privileged scripts should also operate with a carefully controlled environment rather than trusting user-modifiable environment variables.
This is particularly important when a script can be executed through sudo.
Vulnerabilities Covered in TryHackMe Wrong Path
The challenge demonstrates how multiple weaknesses can be chained together:
| Stage | Concept |
|---|---|
| Reconnaissance | Nmap enumeration |
| Web enumeration | Gobuster with PHP extensions |
| Web exploitation | OS command injection |
| Initial access | Remote command execution |
| Post exploitation | Linux filesystem enumeration |
| Credential discovery | Exposed backup files |
| Password security | SHA-512 crypt cracking |
| Authentication | Exposed SSH private key |
| Credential security | Password/passphrase reuse |
| Privilege escalation | Sudo enumeration |
| Linux security | PATH hijacking |
| Final compromise | Root execution |
Lessons Learned
The biggest lesson from TryHackMe Wrong Path is right in the room’s name: the most obvious path isn’t necessarily the correct one.
The web application’s page parameter looked immediately suspicious, but continuing to attack it would have been wasted effort. Returning to enumeration revealed the actual attack surface.
Another important lesson was how vulnerabilities compound.
A vulnerable diagnostic utility provided the initial foothold. Forgotten backups exposed legacy authentication material. Password reuse made an encrypted SSH key useful. Finally, an unsafe privileged backup script turned a normal user account into root access.
Individually, several of these mistakes might appear relatively minor. Combined, they resulted in complete system compromise.
That is what made Wrong Path a particularly useful Boot2Root exercise: the challenge wasn’t just finding one vulnerability. It was recognizing how each discovery connected to the next.