TryHackMe Valley
Complete Walkthrough: Recon to Root

I began with a standard Nmap scan against the assigned room address. Of the default TCP ports tested, only 22/tcp and 80/tcp were open. That gave the investigation two immediate surfaces: SSH for a later authenticated foothold and HTTP for initial enumeration.

Once the site’s /static path was identified, I ran Gobuster directly against it with common.txt. The scan was noisy: many numeric paths returned large files and several requests hit the client timeout. That did not make the results useless. It made response size and manual inspection more important.

The numeric entries—particularly /00—stood out from conventional directory names. Static asset directories are often skipped after the main application paths are found, but predictable filenames can expose content that was never intended to become part of the public interface.

Opening /static/00 returned plain-text development notes. Most entries were harmless content tasks, but one line was operationally valuable: remove /dev1243224123123. The presence of that instruction suggested the path had existed and might still exist.

A second file at /pricing/note.txt complained about notes being left around the website. It did not provide a credential or exploit by itself, but it confirmed a pattern: internal communication was being stored in public web content. That made the first leak much more credible.

The leaked path remained accessible and presented a Valley Photo Co. Dev Login. At this point, brute-forcing the form would have been premature. A development login implemented as a static page is a strong reason to inspect its JavaScript first.

The page source referenced dev.js. Inside it, the login button handler compared the submitted values against hard-coded strings. The same conditional also revealed the redirect target that would be loaded after a successful match.

The destination exposed by the JavaScript contained notes for an FTP server. Two lines matter more than the generic patching reminders: stop reusing credentials and change FTP port to normal port.

Those clues suggest that the FTP service may reuse credentials found elsewhere and may be listening outside its conventional port. The initial Nmap scan did not expose FTP on 21/tcp, which is consistent with the note, while the developer-note filename itself provides a focused port candidate for direct validation.

The filename devNotes37370.txt provided a precise port candidate. Connecting to FTP on 37370 confirmed a vsFTPd 3.0.3 service, and the client-side credentials siemDev / california authenticated successfully. The warning about credential reuse was literal.

The directory contained siemFTP.pcapng, siemHTTP1.pcapng, and siemHTTP2.pcapng. Packet captures are binary files, so trying to use cat inside the FTP client was not a valid way to inspect one. I downloaded siemHTTP2.pcapng with get for local analysis instead.

I opened the downloaded capture in Wireshark and filtered for HTTP POST requests. This reduces a large capture to the traffic most likely to contain submitted form data.

The recovered credentials worked over the SSH service found during the first scan. After logging in as valleyDev, I found user.txt in the home directory and read the user flag.

The first privilege check was sudo -l. It returned that valleyDev may not run sudo on the host, so the straightforward sudo path is closed. The next stage must move into local enumeration: users, groups, processes, scheduled tasks, writable files, capabilities, SUID binaries, and application artifacts.

Local enumeration exposed /home/valleyAuthenticator. I analyzed a copy on the attack machine, first removing its UPX packing and then extracting strings long enough to avoid most binary noise.

The output placed two 32-character hexadecimal values beside the program’s prompts and success messages:

Their length and format suggested MD5. Resolving them produced two plaintext candidates:

Testing the two decoded values against the authenticator established the usable pairing: username valley, password liberty123. From the valleyDev shell, those credentials also worked with su valley and moved the session into a second local account.

The new identity matters because valley belongs to the additional valleyAdmin group. It still has no sudo permission, but its group membership changes which files are writable.

The system crontab revealed a custom task executed by root at minute 1 of every hour:

photosEncrypt.py reads six JPEG files, imports Python’s base64 module, encodes each image, and writes the results into /photos/photoVault. The script itself is owned by root and is not writable by the current account, so editing the cron target directly is not the path.

The important permission appeared on the imported standard-library module:

I added a callback to /usr/lib/python3.8/base64.py, using the VPN address of the attack machine and a listener on port 5555. In another terminal, I started the listener before the scheduled job’s next run.

When root’s cron job imported the modified module, the callback reached the listener as UID 0. Reading /root/root.txt returned the final flag and completed the room.