{"id":412,"date":"2025-11-04T13:28:32","date_gmt":"2025-11-04T13:28:32","guid":{"rendered":"https:\/\/hackingwithj.com\/?p=412"},"modified":"2025-11-04T13:28:32","modified_gmt":"2025-11-04T13:28:32","slug":"thm-valley","status":"publish","type":"post","link":"https:\/\/hackingwithj.com\/?p=412","title":{"rendered":"THM: Valley"},"content":{"rendered":"\n

Back again with the Valley<\/strong> challenge from TryHackMe \u2014 a tidy box with a bit of everything: network analysis, web fuzzing and a little reverse engineering. Good practice and a fun warm-up.<\/p>\n\n\n\n

NMAP<\/h1>\n\n\n\n
nmap -sC -sV -p- -T4 <ip>\nPORT      STATE SERVICE VERSION\n22\/tcp    open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)\n80\/tcp    open  http    Apache httpd 2.4.41 ((Ubuntu))\n| http-methods: \n|_  Supported Methods: HEAD GET POST OPTIONS\n|_http-server-header: Apache\/2.4.41 (Ubuntu)\n|_http-title: Site doesn't have a title (text\/html).\n37370\/tcp open  ftp     vsftpd 3.0.3\nMAC Address: 02:83:0C:3F:32:E9 (Unknown)\nService Info: OSs: Linux, Unix; CPE: cpe:\/o:linux:linux_kernel\nNmap done: 1 IP address (1 host up) scanned in 13.70 seconds\n           Raw packets sent: 65536 (2.884MB) | Rcvd: 65536 (2.621MB)<\/code><\/pre>\n\n\n\n
First thing I checked was the FTP service \u2014 odd port (37370) so it\u2019s worth a look. Anonymous login was attempted but denied, so I moved on to the next sensible target (HTTP) to continue enumeration.<\/p>\n\n\n\n
HTTP (80)<\/h2>\n\n\n\n
Gobuster didn\u2019t reveal anything useful at the root or the usual subdirs, and there was no robots.txt<\/code> or sitemap.xml<\/code>. Something about the \/static<\/code> page kept nagging at me, so I ran Gobuster on that path specifically:<\/p>\n\n\n\n
gobuster dir -u valley.thm\/static -w \/usr\/share\/wordlists\/dirbuster\/directory-list-2.3-medium.txt\n===============================================================\nGobuster v3.6\nby OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)\n===============================================================\n[+] Url:                     http:\/\/valley.thm\/static\n[+] Method:                  GET\n[+] Threads:                 10\n[+] Wordlist:                \/usr\/share\/wordlists\/dirbuster\/directory-list-2.3-medium.txt\n[+] Negative Status codes:   404\n[+] User Agent:              gobuster\/3.6\n[+] Timeout:                 10s\n===============================================================\nStarting gobuster in directory enumeration mode\n===============================================================\n\/12                   (Status: 200) [Size: 2203486]\n\/11                   (Status: 200) [Size: 627909]\n..\n\/7                    (Status: 200) [Size: 5217844]\n\/8                    (Status: 200) [Size: 7919631]\n\/00                   (Status: 200) [Size: 127]\nProgress: 218275 \/ 218276 (100.00%)\n===============================================================\nFinished\n===============================================================<\/code><\/pre>\n\n\n\n
That 00<\/code> entry looked promising \u2014 it was small, which often means a text file or a short page. Navigating to \/static\/00<\/code> revealed a short note from the author and a link to a login form.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
The login form didn\u2019t behave like a normal form: submitting it in the browser produced no network request. I fired up Burp Suite to intercept the attempt and confirmed \u2014 nothing hit the server. That told me the login check is client-side (hardcoded logic in JavaScript), so the next step was to inspect the page source.<\/p>\n\n\n\n
Inside the static folder there was a dev.js<\/code>. Inspecting dev.js<\/code> revealed the expected hardcoded credentials:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
With that credential pair in hand the next clue made sense:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
FTP (37370)<\/h2>\n\n\n\n
That hint pointed at credential reuse: try the same username\/password on other services. The SSH creds weren\u2019t the same, but they worked for FTP on the odd port (37370). Logging in via FTP allowed me to download three files:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Analyzing pcap files<\/h3>\n\n\n\n
I started with siemFTP.pcapng<\/code>. Right away it showed an anonymous FTP login that succeeded \u2014 somebody logged in with empty creds:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Shortly after that we can see the user listing a few files:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Next I opened siemHTTP1.pcapng<\/code> and siemHTTP2.pcapng<\/code>. The capture titles suggested HTTP traffic and, based on experience, I suspected a POST request might contain credentials. In Wireshark I filtered for POSTs:<\/p>\n\n\n\n
http.request.method == \"POST\" <\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
That turned up a login POST that contained a password in the request body. Using that username\/password allowed an SSH login later on. Always check POSTs first when you\u2019re hunting for creds \u2014 it\u2019s one of the first places people leak passwords.<\/p>\n\n\n\n
Initial access<\/h2>\n\n\n\n
With the SSH creds from the pcap I logged in as a lower-privileged user and ran my usual checklist-style enumeration. Most of the obvious checks came up empty, but there was one oddity: a cron job running photosEncrypt.py<\/code> every minute. The script itself didn\u2019t appear to give us an immediate foothold.<\/p>\n\n\n\n
In the user\u2019s home directory I found an executable called valleyAuthenticator<\/code>. I downloaded it and opened it in Ghidra to figure out what it did. <\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
The binary looked packed, so I used UPX to decompress it before re-inspecting:<\/p>\n\n\n\n
upx -d valleyAuthenticator<\/code><\/pre>\n\n\n\n
After unpacking and re-analyzing the binary in Ghidra I found a blob that looked suspiciously like hashed credentials:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
I fed the hashes to CrackStation and got two plaintexts back:<\/p>\n\n\n\n
    \n
  • liberty123<\/li>\n\n\n\n
  • valley<\/li>\n<\/ul>\n\n\n\n
    Those creds gave me access to a new user valley<\/code> \u2014 who, importantly, is part of a valleyAdmin<\/code> group.<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    Privilege escalation<\/h2>\n\n\n\n
    The valley<\/code> home directory didn\u2019t immediately reveal anything useful, so I searched for files owned by (or accessible to) the valleyAdmin<\/code> group:<\/p>\n\n\n\n
    valley@valley:~$ find \/ -group valleyAdmin -type f 2>\/dev\/null\n\/usr\/lib\/python3.8\/base64.py<\/code><\/pre>\n\n\n\n
    That was the eureka moment. A core Python library (base64.py<\/code>) was writable by a group that included valley<\/code>, and the writable library is used by a script that runs as root (the photosEncrypt.py<\/code> cronjob you noticed earlier). In short: a script running as root imports a module we can modify. I modified the library so that when the root-owned script imports it, my injected payload runs with root privileges:<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    invoke bash -p<\/code> to keep the elevated permissions. After the system executed the altered library via the root cronjob, I ran:<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    \u2026and I had a root shell.<\/p>\n\n\n\n
    Why this works (short explanation):<\/strong> when a root-owned process imports a module that an attacker can edit, any code in that module will execute as root. By inserting a command that gives the attacker a persistent escalation (SUID on a root shell), you can escalate to root when the vulnerable process runs. This is why writable system libraries or dependencies are a major misconfiguration.<\/p>\n\n\n\n
    Learning notes<\/h2>\n\n\n\n
    Reverse engineering<\/strong><\/p>\n\n\n\n
      \n
    • Unpack first, inspect second: try UPX \u2192 Ghidra\/IDA \u2192 strings \u2192 decompiled functions.<\/li>\n\n\n\n
    • Focus on I\/O and auth routines: look for hardcoded keys, checksum routines, and network endpoints.<\/li>\n\n\n\n
    • Extract any embedded hashes\/credentials and test them offline (hashcat\/john) before trying online.<\/li>\n\n\n\n
    • Keep tooling handy: upx<\/code>, ghidra<\/code>, radare2<\/code>, strings<\/code>, binwalk<\/code>.<\/li>\n<\/ul>\n\n\n\n
      Privilege escalation through core system files<\/strong><\/p>\n\n\n\n
        \n
      • Check writable libraries and modules: find \/ -writable -type f 2>\/dev\/null<\/code> and find \/ -group <group> -type f<\/code>.<\/li>\n\n\n\n
      • Audit cronjobs and services that run as root \u2014 anything they import or execute is an escalation target.<\/li>\n\n\n\n
      • If a root process loads a modifiable dependency, you can inject code that executes as root (SUID bash, reverse shell, etc.).<\/li>\n<\/ul>\n\n\n\n
        PCAP analysis<\/strong><\/p>\n\n\n\n
          \n
        • Start with obvious filters: http.request.method == \"POST\"<\/code>, ftp<\/code>, smtp<\/code> \u2014 creds often show up in POST bodies or plain protocols.<\/li>\n\n\n\n
        • Use follow-streams and export objects (HTTP, files) \u2014 they often hide config files or credentials.<\/li>\n<\/ul>\n\n\n\n
          <\/p>\n","protected":false},"excerpt":{"rendered":"
          Back again with the Valley challenge from TryHackMe \u2014 a tidy box with a bit of everything: network analysis, web fuzzing and a little reverse engineering. Good practice and a fun warm-up. NMAP First thing I checked was the FTP service \u2014 odd port (37370) so it\u2019s worth a look. Anonymous login was attempted but […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"site-container-style":"default","site-container-layout":"default","site-sidebar-layout":"default","disable-article-header":"default","disable-site-header":"default","disable-site-footer":"default","disable-content-area-spacing":"default","footnotes":""},"categories":[8],"tags":[],"class_list":["post-412","post","type-post","status-publish","format-standard","hentry","category-ctf"],"_links":{"self":[{"href":"https:\/\/hackingwithj.com\/index.php?rest_route=\/wp\/v2\/posts\/412","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hackingwithj.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hackingwithj.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hackingwithj.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/hackingwithj.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=412"}],"version-history":[{"count":4,"href":"https:\/\/hackingwithj.com\/index.php?rest_route=\/wp\/v2\/posts\/412\/revisions"}],"predecessor-version":[{"id":429,"href":"https:\/\/hackingwithj.com\/index.php?rest_route=\/wp\/v2\/posts\/412\/revisions\/429"}],"wp:attachment":[{"href":"https:\/\/hackingwithj.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=412"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hackingwithj.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=412"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hackingwithj.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=412"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}